Re: [PATCH RFC 0/5] Scan all devices to build fs device list

[Anand Jain <Anand.Jain@oracle.com>]

Goffredo,


Thanks for comments, more in line below.

On 10/09/2014 04:31, Goffredo Baroncelli wrote:
> On 09/09/2014 05:26 AM, Anand Jain wrote:
>
> Anand,
> first thanks to discuss this with me; below my comments
>
>>> You are talking about a ioctl: why not use (extending them when needed)
>>> the sysfs information ?
>>
>>   yeah, I understand I am the only person talking about ioctl,
>>   and all others recommend sysfs. I understand I am wrong, but
>>   just by mass. and I still have no idea why not ioctl ?
>
> Because it is an interface difficult to extend.

  Its quite common to make ioctl auto adaptable by using the
  structure size/version.  btrfs-devlist tool does it too.


>>   Problem with sysfs:
>>    - Note that sysfs supports only one parameter value with max length
>>    u64, to rebuilt entire kernel's fs_uuid list in the user space
>>    that would be quite a lot of sysfs files. should that be fine ?
>>    Further we would need another traverser tool (python ?) to read
>>    all these sysfs files. ? so that we could create fs_uuid list
>>    in the user-space.
> To me it seems that other fs interface scale well even if the number
> of items is big (think /proc)

  /proc supports larger content transfer using seq_file.  /sysfs doesn't.

>>    - we would need all info about the kernel fs_uuid, even when the
>>   device is not mounted.

> Could you elaborate ?
> We have two kind of objects: filesystems and devices. A filesystem is
> created when its first device is registered. When the filesystem
> is mounted, further information are available.
>
> Our hypothetical sysfs interface should export information about
> filesystem and/or devices until they exist. If a filesystem is
> mounted more information are exported. When it is umounted
> less are exported.
>
> This would not be different if we use a ioctl() interface.

  (Its not an on disk structure)
  The purpose of this interface is to read entire of volume.c
  static LIST_HEAD(fs_uuids) list from the btrfs memory to the
  user space. Sorry if it wasn't clear before.

  We desperately need this to solve some critical structural
  problem in btrs-progs.

>>    - thinking of nested seed with sysfs is more complicated, as we would
>>   have same btrfs_device at multiple fs_devices. still we must represent
>>   them in the sysfs.
> I am not used to use seed device; so I can't comment.
>
>>    - as of now fs_uuid can grow infinite with just "a" device.
>>     ref: [PATCH 1/2] btrfs: device list could grow infinite
> This is a btrfs problem. Doesn't make sense to store these information
> if there aren't any device. When the last device disappear (is replaced),
> the filesystem object should disappear too.
> If a sysfs approach point out this problem... to me it seems good ! :-)


>>     can't imagine anybody traversing through /sysfs to understand
>>     what btrfs-kernel think of devices. user would prefer a cli
>>     to know that instead.
> sysfs is an interface, that doesn't means that is THE user interface.
> Of course a CLI or a GUI will need.


>>
>>    - sysfs layout has to be dynamic based on fs_uuids list changes,
>>    devices added, removed, mounted replaced etc.. isn't it making
>>    more unstable ?
>
> $ find /sys | wc -l
> 27362
> On my PC sysfs has more already than 20 thousands entries, and it is
> a quite simple machine. But this doesn't cause instability.
> May be more difficult, but I don't think that sysfs is not capable
> to sustain that.
>
>
> Already linux export a lot of sysfs files for each device. I.e.
>
> $ find /sys/block/sda/ | wc -l
> 	190
>
> these are hundreds entries for each disks. So I don't think that btrfs sysfs
> interface could cause more problem even if a filesystem has
> a lot of disks.


>>
>> appreciate your comments
> The major problem of an ioctl() interface is that is very difficult
> to extend. Typically when we need to extend it , the current is
> marked as old/deprecated and a new one is generated.
> However an ioctl() is an ABI so even the old interface have to be
> maintained.
>
> One point about I have to agree with you is that a sysfs interface
> is not good, is when:
> - we need to export huge quantity of data
> - we have an high rate of data
>
> But these to me don't seem to apply to a sysfs btrfs interface.


  I thought you will say sysfs doesn't have to depend on any
  custom made user space tool to read/write. :-)

  The challenge is to provide sysfs interface without cluttering
  it.  There are a lot talks on sysfs being cluttered.
  We definitely need sysfs interface for btrfs. But I am not
  too sure if we can get all the info without looking btrfs sysfs
  interface too cluttered, typically we might need all info as
  in btrfs-devlist.

Thanks, Anand