From: Anand Jain <Anand.Jain@oracle.com>
To: Eric Sandeen <sandeen@redhat.com>, btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: know mount location with in FS
Date: Tue, 18 Feb 2014 11:06:38 +0800 [thread overview]
Message-ID: <5302CE3E.6010800@oracle.com> (raw)
In-Reply-To: <5302453B.8000509@redhat.com>
> 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
next prev parent reply other threads:[~2014-02-18 2:56 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-16 15:02 know mount location with in FS Anand Jain
2014-02-17 17:22 ` Eric Sandeen
2014-02-18 3:06 ` Anand Jain [this message]
2014-02-18 8:40 ` Goswin von Brederlow
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5302CE3E.6010800@oracle.com \
--to=anand.jain@oracle.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=sandeen@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).