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. > 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) > - 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. > > - 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. > > Anand > -- gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
