On Sun, Apr 12, 2009 at 3:01 PM, Kay Sievers <kay.siev...@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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
