Re: know mount location with in FS
On Tue, Feb 18, 2014 at 11:06:38AM +0800, Anand Jain wrote: For what reason? Remember that a single block device can be mounted in multiple places (or bind-mounted, etc), so there is not even necessarily a single answer to that question. -Eric Yes indeed. (the attempt is should we be able to maintain all the mount points as a list saved/updated under per fs_devices. ?) some of the exported symbols at fs/namei.c looks closely related to the purpose here, but it didn't help unless I missed something. any comment is helpful.. The reason: First of all btrfs-progs has used scan-all-disks very liberally which isn't a scalable design (imagine a data center with 1000's of LUN). Even a simple check_mounted() does scan-all-disks (when total_disk 1), that isn't necessary if the kernel could let it know. Scan for btrfs has expensive steps of reading each super-block, and the effect is, in general most of the btrfs-progs commands are very very slow when things like scrub is running. check_mounted() fails when seeding is used (since /proc/self/mounts would show disk with lowest devid and in most common scenario it will be a seed disk. (which has different FSID from the actual disk in question). and Further most severe problem is some btrfs-progs threads has been scan-all-disks more than once during the thread's life time. So a total revamp of this design has become an immediate need. What I am planning is - btrfs-progs to init btrfs-disk-list once per required thread (mostly use BTRFS_IOC_GET_DEVS, which would dump anything and everything about the btrfs devices) - the btrfs-disk-list is obtained from kernel first, and will fill with the remaining disks which kernel isn't aware of. - If the step one also provides the mount point(s) from the kernel that would complete the loop with what end user would want to know. Thanks, Anand What about mountpoints outside the current filesystem namespace or ones that should be shortened to the filesystem namespace (e.g. in a chroot the leading dirs need to be cut)? MfG Goswin -- 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: know mount location with in FS
On 2/16/14, 9:02 AM, Anand Jain wrote: Hello, I wonder if there is any known way to get the mount point directory name with in the btrfs-kernel ? For what reason? Remember that a single block device can be mounted in multiple places (or bind-mounted, etc), so there is not even necessarily a single answer to that question. -Eric -- 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: know mount location with in FS
For what reason? Remember that a single block device can be mounted in multiple places (or bind-mounted, etc), so there is not even necessarily a single answer to that question. -Eric Yes indeed. (the attempt is should we be able to maintain all the mount points as a list saved/updated under per fs_devices. ?) some of the exported symbols at fs/namei.c looks closely related to the purpose here, but it didn't help unless I missed something. any comment is helpful.. The reason: First of all btrfs-progs has used scan-all-disks very liberally which isn't a scalable design (imagine a data center with 1000's of LUN). Even a simple check_mounted() does scan-all-disks (when total_disk 1), that isn't necessary if the kernel could let it know. Scan for btrfs has expensive steps of reading each super-block, and the effect is, in general most of the btrfs-progs commands are very very slow when things like scrub is running. check_mounted() fails when seeding is used (since /proc/self/mounts would show disk with lowest devid and in most common scenario it will be a seed disk. (which has different FSID from the actual disk in question). and Further most severe problem is some btrfs-progs threads has been scan-all-disks more than once during the thread's life time. So a total revamp of this design has become an immediate need. What I am planning is - btrfs-progs to init btrfs-disk-list once per required thread (mostly use BTRFS_IOC_GET_DEVS, which would dump anything and everything about the btrfs devices) - the btrfs-disk-list is obtained from kernel first, and will fill with the remaining disks which kernel isn't aware of. - If the step one also provides the mount point(s) from the kernel that would complete the loop with what end user would want to know. 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
know mount location with in FS
Hello, I wonder if there is any known way to get the mount point directory name with in the btrfs-kernel ? 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
