All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.