Re: [PATCH RFC 0/5] Scan all devices to build fs device list
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 0/5] Scan all devices to build fs device list
On Sat, Sep 06, 2014 at 04:05:20PM -0400, Chris Mason wrote: On 09/03/2014 09:36 AM, Miao Xie wrote: This patchset implements device list automatic building function. As we know, currently we need scan the devices to build device list by a user tool before mounting the filesystem, especially mount the filesystem after we re-install btrfs module. It is not convenient. This patchset can improve that problem. With this patchset, we will scan all the devices in the system to build the device list if we find the number of the devices is not right when we mount the filesystem. By this way, we needn't scan the device by the user tool and reduce the mount failure probability due to the incomplete device list. Thanks for working on these patches, but I really prefer that we do these scans from userspace. I agree. The userspace approach gives more control of when and how the scanning is done. Yes the scan has to be done after the module is inserted, but distros have that in initrd. Reinstalling module is not something a normal user does and developers know how to workaround. Automatic scanning in usperspace can be done via the mount helper and this is IMO the way to go. There's a patch for that from Goffredo, not merged yet, the patch backlog is still too long. -- 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
Re: [PATCH RFC 0/5] Scan all devices to build fs device list
On 08/09/2014 17:09, David Sterba wrote: On Sat, Sep 06, 2014 at 04:05:20PM -0400, Chris Mason wrote: On 09/03/2014 09:36 AM, Miao Xie wrote: This patchset implements device list automatic building function. As we know, currently we need scan the devices to build device list by a user tool before mounting the filesystem, especially mount the filesystem after we re-install btrfs module. It is not convenient. This patchset can improve that problem. With this patchset, we will scan all the devices in the system to build the device list if we find the number of the devices is not right when we mount the filesystem. By this way, we needn't scan the device by the user tool and reduce the mount failure probability due to the incomplete device list. Thanks for working on these patches, but I really prefer that we do these scans from userspace. I agree. The userspace approach gives more control of when and how the scanning is done. Yes the scan has to be done after the module is inserted, but distros have that in initrd. Reinstalling module is not something a normal user does and developers know how to workaround. Automatic scanning in usperspace can be done via the mount helper and this is IMO the way to go. There's a patch for that from Goffredo, not merged yet, the patch backlog is still too long. Since we are on the topic of scanning. A point on improving the btrfs-progs scan method which I am working on... - Scan of all system devices is an expensive task. But btrfs-progs do it very liberally. Due to this there are some serious problem like - btrfs fi show is too slow when scrub is running. - The worst is Single btrfs-progs thread scans for btrfs devices multiple times. Mainly because most of the functions uses check_mounted() which in turn calls scan, think of multi device btrfs config. - The problem would be more prominent in larger server with 1000's of LUNs / devices. - lblkid can be the only method to scan for devices. (The other method we have as of now is of canning /proc/partitions, which lblkid also does). what I am planning - Use btrfs control ioctl to help btrfs-progs check_mounted() to know if a (multi) device is mounted. Build kernel's fs_devices list in the user-space using btrfs control ioctl. Do device scan only once per btrfs-progs thread. Any comments ? Thanks, Anand -- 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
Re: [PATCH RFC 0/5] Scan all devices to build fs device list
Hi David, On 09/08/2014 11:09 AM, David Sterba wrote: Automatic scanning in usperspace can be done via the mount helper and this is IMO the way to go. There's a patch for that from Goffredo, not merged yet, the patch backlog is still too long. There is something that I can do to help you regarding this patch ? -- 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
Re: [PATCH RFC 0/5] Scan all devices to build fs device list
On 09/08/2014 01:04 PM, Anand Jain wrote: On 08/09/2014 17:09, David Sterba wrote: On Sat, Sep 06, 2014 at 04:05:20PM -0400, Chris Mason wrote: On 09/03/2014 09:36 AM, Miao Xie wrote: This patchset implements device list automatic building function. As we know, currently we need scan the devices to build device list by a user tool before mounting the filesystem, especially mount the filesystem after we re-install btrfs module. It is not convenient. This patchset can improve that problem. With this patchset, we will scan all the devices in the system to build the device list if we find the number of the devices is not right when we mount the filesystem. By this way, we needn't scan the device by the user tool and reduce the mount failure probability due to the incomplete device list. Thanks for working on these patches, but I really prefer that we do these scans from userspace. I agree. The userspace approach gives more control of when and how the scanning is done. Yes the scan has to be done after the module is inserted, but distros have that in initrd. Reinstalling module is not something a normal user does and developers know how to workaround. Automatic scanning in usperspace can be done via the mount helper and this is IMO the way to go. There's a patch for that from Goffredo, not merged yet, the patch backlog is still too long. Since we are on the topic of scanning. A point on improving the btrfs-progs scan method which I am working on... - Scan of all system devices is an expensive task. But btrfs-progs do it very liberally. Due to this there are some serious problem like - btrfs fi show is too slow when scrub is running. - The worst is Single btrfs-progs thread scans for btrfs devices multiple times. Mainly because most of the functions uses check_mounted() which in turn calls scan, think of multi device btrfs config. Using libblkid (see your proposal below) would help in this case, because the values would be cached. - The problem would be more prominent in larger server with 1000's of LUNs / devices. - lblkid can be the only method to scan for devices. (The other method we have as of now is of canning /proc/partitions, which lblkid also does). what I am planning - Use btrfs control ioctl to help btrfs-progs check_mounted() to know if a (multi) device is mounted. Build kernel's fs_devices list in the user-space using btrfs control ioctl. Do device scan only once per btrfs-progs thread. You are talking about a ioctl: why not use (extending them when needed) the sysfs information ? Any comments ? Thanks, Anand -- 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 -- 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
Re: [PATCH RFC 0/5] Scan all devices to build fs device list
Since we are on the topic of scanning. A point on improving the btrfs-progs scan method which I am working on... - Scan of all system devices is an expensive task. But btrfs-progs do it very liberally. Due to this there are some serious problem like - btrfs fi show is too slow when scrub is running. - The worst is Single btrfs-progs thread scans for btrfs devices multiple times. Mainly because most of the functions uses check_mounted() which in turn calls scan, think of multi device btrfs config. Using libblkid (see your proposal below) would help in this case, because the values would be cached. may be, let me try / report. but first I need to search for a system with at least 100+ LUNs. - The problem would be more prominent in larger server with 1000's of LUNs / devices. - lblkid can be the only method to scan for devices. (The other method we have as of now is of canning /proc/partitions, which lblkid also does). what I am planning - Use btrfs control ioctl to help btrfs-progs check_mounted() to know if a (multi) device is mounted. Build kernel's fs_devices list in the user-space using btrfs control ioctl. Do device scan only once per btrfs-progs thread. 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 ? 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. - we would need all info about the kernel fs_uuid, even when the device is not mounted. - 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. - as of now fs_uuid can grow infinite with just a device. ref: [PATCH 1/2] btrfs: device list could grow infinite 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 layout has to be dynamic based on fs_uuids list changes, devices added, removed, mounted replaced etc.. isn't it making more unstable ? appreciate your comments Anand -- 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
Re: [PATCH RFC 0/5] Scan all devices to build fs device list
On 09/03/2014 09:36 AM, Miao Xie wrote: This patchset implements device list automatic building function. As we know, currently we need scan the devices to build device list by a user tool before mounting the filesystem, especially mount the filesystem after we re-install btrfs module. It is not convenient. This patchset can improve that problem. With this patchset, we will scan all the devices in the system to build the device list if we find the number of the devices is not right when we mount the filesystem. By this way, we needn't scan the device by the user tool and reduce the mount failure probability due to the incomplete device list. Thanks for working on these patches, but I really prefer that we do these scans from userspace. I know it introduces a few problems, but it also solves a lot of complexity at the same time. And udev already has most of the info we need, so I think our time is best spent fixing any problems with the udev integration. -chris -- 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
[PATCH RFC 0/5] Scan all devices to build fs device list
This patchset implements device list automatic building function. As we know, currently we need scan the devices to build device list by a user tool before mounting the filesystem, especially mount the filesystem after we re-install btrfs module. It is not convenient. This patchset can improve that problem. With this patchset, we will scan all the devices in the system to build the device list if we find the number of the devices is not right when we mount the filesystem. By this way, we needn't scan the device by the user tool and reduce the mount failure probability due to the incomplete device list. --- Miao Xie (5): block: export disk_class and disk_type for btrfs Btrfs: don't return btrfs_fs_devices if the caller doesn't want it Btrfs: restructure btrfs_scan_one_device Btrfs: restructure btrfs_get_bdev_and_sb and pick up some code used later Btrfs: scan all the devices and build the fs device list by btrfs's self block/genhd.c | 7 +- fs/btrfs/super.c | 3 + fs/btrfs/volumes.c| 227 -- fs/btrfs/volumes.h| 5 +- include/linux/genhd.h | 1 + 5 files changed, 177 insertions(+), 66 deletions(-) -- 1.9.3 -- 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
