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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
