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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
