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
--
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
