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