Hi,
I have a question about how btrfs is supposed to work with
/proc/self/mountinfo. It appears that the dev_t isn''t matching what
one would expect when mounting a btrfs filesystem - here''s /dev/sdb2
mounted at /media/usb-fedora
# cat /proc/self/mountinfo |grep btrfs
17 19 0:19 / /media/usb-fedora rw,nosuid,nodev,relatime - btrfs /dev/sdb2 rw
I would expect to see 8:18 corresponding to /dev/sdb2.
This makes it a bit hard for user space to figure out whether a given
device (such as /dev/sdb2) is mounted. We need this kind of
information in the desktop shell (e.g. Nautilus) and partitioning
programs to tell the user that a device or partition is currently part
of a mounted file system (and if so, what filesystem).
We also want to do this using dev_t (e.g. not rely on device node
names) using /proc/self/mountinfo since /proc/mounts and /etc/mtab
have well-known flaws and it''s never a good idea to use device node
names anyway.
So. My guess is that the reason I''m seeing an unnamed block device
(0:19) has to do with the fact that a btrfs filesystem can use
multiple devices. In fact, I guess it''s entirely possible that a user
could add a new disk, mirror the mounted filesystem onto, say,
/dev/sdc1 and then detach /dev/sdb2. Then you''d end up with only
having bits on /dev/sdc1. So if this is one goal (and I hope it is, it
sounds really useful), then referencing dev_t of the physical devices
in /proc/self/mountinfo of course won''t work.
But we''d still need some kind of way of having the kernel tell user
space what devices are currently claimed by the btrfs filesystem
instance (and we''d need notifications on changes too). Otherwise we
don''t have enough information for the desktop shell and partitioning
programs to let the user know that /dev/sdb2 or /dev/sdc1 or whatever
is currently claimed by the 0:19 btrfs mount at /media/fedora-usb.
One idea is to have a pollable file, /proc/fs/btrfs/devs, that maps
from the dev_t of the btrfs filesystem instance (as used in
/proc/self/mountinfo) to the set of dev_t for block devices currently
claimed? E.g. for the example above we''d have
/proc/fs/btrfs/devs:
0:19 8:18
That way, user space can look up that file when encountering 0:19 in
/proc/self/mountinfo and also listen for changes when the block
devices are added/removed to the btrfs filesystem instance. I''m just
thinking out loud here.
Apologies if this has been discussed previously or if there already is
a way to get this information.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Apr 12, 2009 at 07:35, David Zeuthen <zeuthen@gmail.com> wrote:> But we''d still need some kind of way of having the kernel tell user > space what devices are currently claimed by the btrfs filesystem > instance (and we''d need notifications on changes too). Otherwise we > don''t have enough information for the desktop shell and partitioning > programs to let the user know that /dev/sdb2 or /dev/sdc1 or whatever > is currently claimed by the 0:19 btrfs mount at /media/fedora-usb. > > One idea is to have a pollable file, /proc/fs/btrfs/devs, that maps > from the dev_t of the btrfs filesystem instance (as used in > /proc/self/mountinfo) to the set of dev_t for block devices currently > claimed? E.g. for the example above we''d have > > /proc/fs/btrfs/devs: > 0:19 8:18Btrfs used to export some information in /sys/fs/btrfs/, this is disabled for now. Maybe we can possibly make it export something like: $ tree /sys/fs/btrfs/ /sys/fs/btrfs/ |-- 969d1386-a002-4c28-94f2-47be23f344e4 | |-- ba1532f3-849b-400b-9c76-2c9aee126c52 | | |-- device -> ../../../devices/.../block/sda/sda3 | | |-- attribute1 | | |-- ... | `-- 45645656-849b-400b-9c76-2c9aee126c52 | |-- device -> ../../../devices/.../block/sdb/sdb3 | |-- attribute1 | .... `-- 645645686-a002-4c28-94f2-47be23f344e4 |-- ... So you could look for a "device" link at the subvolume devices? Or if that does not fit for some reason, we could also add a "btrfs" class, to export details about the subvolumes. Thanks, Kay -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Apr 12, 2009 at 3:01 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:> Btrfs used to export some information in /sys/fs/btrfs/, this is > disabled for now. Maybe we can possibly make it export something like: > $ tree /sys/fs/btrfs/ > /sys/fs/btrfs/ > |-- 969d1386-a002-4c28-94f2-47be23f344e4 > | |-- ba1532f3-849b-400b-9c76-2c9aee126c52 > | | |-- device -> ../../../devices/.../block/sda/sda3 > | | |-- attribute1 > | | |-- ... > | `-- 45645656-849b-400b-9c76-2c9aee126c52 > | |-- device -> ../../../devices/.../block/sdb/sdb3 > | |-- attribute1 > | .... > `-- 645645686-a002-4c28-94f2-47be23f344e4 > |-- ... > > > So you could look for a "device" link at the subvolume devices? Or if > that does not fit for some reason, we could also add a "btrfs" class, > to export details about the subvolumes.I guess that either approach would work. The important thing for me is to figure out what block devices are part of a mounted btrfs volume including getting change notifications. This also includes the mount point and the mount options so I think some kind information "linking" entries in /proc/self/mountinfo to /sys/fs/btrfs would be helpful. For example if /sys/fs/btrfs looked like this $ tree /sys/fs/btrfs/ /sys/fs/btrfs/ |-- 0:19 | | 969d1386-a002-4c28-94f2-47be23f344e4 | | |-- ba1532f3-849b-400b-9c76-2c9aee126c52 | | | |-- device -> ../../../../devices/.../block/sda/sda3 | | | |-- attribute1 | | | |-- ... | | `-- 45645656-849b-400b-9c76-2c9aee126c52 | | |-- device -> ../../../../devices/.../block/sdb/sdb3 | | |-- attribute1 | | .... |-- 0:20 | `-- 645645686-a002-4c28-94f2-47be23f344e4 | |-- ... then it''s really easy to figure out that sda3 and sdb3 are both active subvolumes of the btrfs volume 969d1386-a002-4c28-94f2-47be23f344e4 that is mounted with dev_t 0:19. E.g. the app would go through /proc/self/mountinfo, see that 0:19 is mounted at /foo with options bar,baz, see that the fstype is ''btrfs'' and then look up /sys/fs/btrfs/0:19 to get the subvolumes. Ideally we''d also get events (POLLPRI or POLLERR) on /proc/self/mountinfo when btrfs subvolumes are attached and detached. (apologies if ''active'', ''attached'' and ''detached'' isn''t proper btrfs lingo) I mean, this approach probably require the least amount of changes to apps if they want to properly support btrfs. I think at least *some* changes are to be expected due to the multi-disk nature of btrfs. There might be an easier way to solve this, I don''t know. Perhaps if every btrfs subvolume had an entry in /proc/self/mountinfo at least some legacy apps wouldn''t need modifications... yet others would probably fail... I don''t know. David -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
It would be nice to keep legacy compatibility for the most common case - one filesystem on one device with one active subvolume. If that is true, then it is important btrfs should look like any other filesystem to userspace apps reading /proc/self/mountinfo ----- Original Message ----- From: "David Zeuthen" <zeuthen@gmail.com> To: "Kay Sievers" <kay.sievers@vrfy.org> Cc: <linux-btrfs@vger.kernel.org> Sent: Sunday, April 12, 2009 10:08 PM Subject: Re: btrfs and /proc/self/mountinfo On Sun, Apr 12, 2009 at 3:01 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:> Btrfs used to export some information in /sys/fs/btrfs/, this is > disabled for now. Maybe we can possibly make it export something like: > $ tree /sys/fs/btrfs/ > /sys/fs/btrfs/ > |-- 969d1386-a002-4c28-94f2-47be23f344e4 > | |-- ba1532f3-849b-400b-9c76-2c9aee126c52 > | | |-- device -> ../../../devices/.../block/sda/sda3 > | | |-- attribute1 > | | |-- ... > | `-- 45645656-849b-400b-9c76-2c9aee126c52 > | |-- device -> ../../../devices/.../block/sdb/sdb3 > | |-- attribute1 > | .... > `-- 645645686-a002-4c28-94f2-47be23f344e4 > |-- ... > > > So you could look for a "device" link at the subvolume devices? Or if > that does not fit for some reason, we could also add a "btrfs" class, > to export details about the subvolumes.I guess that either approach would work. The important thing for me is to figure out what block devices are part of a mounted btrfs volume including getting change notifications. This also includes the mount point and the mount options so I think some kind information "linking" entries in /proc/self/mountinfo to /sys/fs/btrfs would be helpful. For example if /sys/fs/btrfs looked like this $ tree /sys/fs/btrfs/ /sys/fs/btrfs/ |-- 0:19 | | 969d1386-a002-4c28-94f2-47be23f344e4 | | |-- ba1532f3-849b-400b-9c76-2c9aee126c52 | | | |-- device -> ../../../../devices/.../block/sda/sda3 | | | |-- attribute1 | | | |-- ... | | `-- 45645656-849b-400b-9c76-2c9aee126c52 | | |-- device -> ../../../../devices/.../block/sdb/sdb3 | | |-- attribute1 | | .... |-- 0:20 | `-- 645645686-a002-4c28-94f2-47be23f344e4 | |-- ... then it''s really easy to figure out that sda3 and sdb3 are both active subvolumes of the btrfs volume 969d1386-a002-4c28-94f2-47be23f344e4 that is mounted with dev_t 0:19. E.g. the app would go through /proc/self/mountinfo, see that 0:19 is mounted at /foo with options bar,baz, see that the fstype is ''btrfs'' and then look up /sys/fs/btrfs/0:19 to get the subvolumes. Ideally we''d also get events (POLLPRI or POLLERR) on /proc/self/mountinfo when btrfs subvolumes are attached and detached. (apologies if ''active'', ''attached'' and ''detached'' isn''t proper btrfs lingo) I mean, this approach probably require the least amount of changes to apps if they want to properly support btrfs. I think at least *some* changes are to be expected due to the multi-disk nature of btrfs. There might be an easier way to solve this, I don''t know. Perhaps if every btrfs subvolume had an entry in /proc/self/mountinfo at least some legacy apps wouldn''t need modifications... yet others would probably fail... I don''t know. David -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, 2009-04-12 at 10:35 -0400, David Zeuthen wrote:> Hi, > > I have a question about how btrfs is supposed to work with > /proc/self/mountinfo. It appears that the dev_t isn''t matching what > one would expect when mounting a btrfs filesystem - here''s /dev/sdb2 > mounted at /media/usb-fedora > > # cat /proc/self/mountinfo |grep btrfs > 17 19 0:19 / /media/usb-fedora rw,nosuid,nodev,relatime - btrfs /dev/sdb2 rw >Yes, this is because I switched to an anonymous super to remove restrictions about which devices could be removed from a mounted filesystem. Today it is possible to do something like this: mkfs.ext3 /dev/sdb mkfs.ext3 /dev/sdc mount /dev/sdb /mnt mount /dev/sdc /mnt Which gives me this in mountinfo: 29 14 8:16 / /mnt rw - ext3 /dev/sdb rw,errors=continue,data=ordered 31 29 8:32 / /mnt rw - ext3 /dev/sdc rw,errors=continue,data=ordered So, applications can already see duplicate device entries for the same mount point. Do they deal with that today? I''m not sure I''ll be able to get control over the dev_ts mountinfo spits out just for btrfs, but we can always float a patch. Otherwise, we''ll have to use the sysfs goo Kay is working on. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html