On Tue, Jun 03, 2014 at 11:36:04AM +0800, Anand Jain wrote:
> From: Anand Jain <anand.j...@oracle.com>
> 
> As of now with out this patch the sysfs interface under dir
> /sys/fs/btrfs/<fsid>/devices is just link to the block devs.

At this point it's part of the sysfs ABI and should not be changed.

> Moving forward we would need the above btrfs sysfs path to contain more
> info about the btrfs devices. So this patch provides a framework for
> the same.

I'd prefer a separate directory for that, Hugo once sent a proposal for
that, /sys/fs/btrfs/devmap/... with enhanced information about the
devices

http://article.gmane.org/gmane.comp.file-systems.btrfs/32410

but was not a per-filesystem list of devices as your patch introduces. I
think we should consider something similar to the /dev/disk/... symlink
structure, both per-module and per-filesystem.

Example:

/sys/fs/btrfs/devmap/by-id/
  contains directories with integer numbers that represent devices

/sys/fs/btrfs/devmap/by-uuid/
  symlink to the corresponding by-id directory based on the device uuid

/sys/fs/btrfs/devmap/by-dev/
  dtto but by the the physical device name

I take the device id as the primary reference to the devices, the
physical block devices may differ, but the ids are stable.

The by-id/by-uuid/by-dev are there for users' convenience.

The /sys/fs/btrfs/<uuid>/ directory would contain subset of the devmap
and has symlinks to /sys/fs/btrfs/devmap directories.

This should present the general idea of the device-related directories,
naming or other tweaking is possible.

The existing directory 'devices' links to the physical devices (located
in sysfs), while the devmap represents the btrfs module POV, so this is
not duplicate.

> And as of now a probe interface is added, which can be used to notify
> btrfs for any change in the device status.

So, the probe  would be located in the 'by-id/n' directory.
--
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

Reply via email to