linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Mahoney <jeffm@suse.com>
To: Goffredo Baroncelli <kreijack@gmail.com>, linux-btrfs@vger.kernel.org
Subject: Re: [RFC][PATCH] BTRFS_PROG: mount.btrfs helper
Date: Sun, 03 Nov 2013 16:23:32 -0500	[thread overview]
Message-ID: <5276BED4.4060707@suse.com> (raw)
In-Reply-To: <1383503921-6694-1-git-send-email-kreijack@inwind.it>

[-- Attachment #1: Type: text/plain, Size: 2187 bytes --]

On 11/3/13, 1:38 PM, Goffredo Baroncelli wrote:
> Hi all,
> 
> this patch provides a mount.btrfs helper for the mount command to
> mounting a btrfs filesystem.
> A btrfs filesystem could spans several disks. This helper scans all
> the partition to discover all the disks required to mount a filesystem.
> So it is not necessary any-more to "scan" manually the partitions to mount
> a filesystem via the "btrfs device scan" command.
> 
> It adds in the option parameters the devices required to mount a
> filesystem. Supposing that a filesystem is composed by several disks
> (/dev/sd[cdef]), when the user does "mount /dev/sdd /mnt", mount calls
> mount.btrfs which int turn calls the mount(2) syscall like:
> mount("/dev/sdd", "/mnt", "btrfs", 0,
> "device=/dev/sdc,device=/dev/sde,device=/de/vsdf").
> 
> This helper uses both the libblkid and libmount to discover the
> devices, to compute the parameters manipulation and to update the mtab
> file.
> 
> I got the idea from the btrfs.wiki; its biggest gains is to avoid the
> separation of scanning phases (at boot time or during the block device
> discovery) from the mounting. Also mkfs.btrfs could avoid to re-do a
> rescan of the devices after a formatting.
> 
> mount.btrfs doesn't add more requirement than the mount command. It
> would be possible to remove the "btrfs" command from the initramfs, and
> all the related scripts (in my debian both udev and btrfs-tools
> packages contains three udev rules for btrfs).
> 
> Comments are welcome.

I like the idea but I'm concerned how well this will perform on large
systems with thousands of disks attached. btrfs dev scan can have a list
of potential devices specified, but this helper defaults to all devices.
A quick test run with 2000 scsi_debug targets shows that btrfs dev scan
can take 8 seconds, and that's with no actual I/O occurring. I don't
think we want to specify the list of devices to scan on the mount
command line, but perhaps an /etc config file that limits the scan to a
list of devices (and defaults to all) similar to how mdadm.conf works
would be a good improvement.

-Jeff


-- 
Jeff Mahoney
SUSE Labs


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 841 bytes --]

  parent reply	other threads:[~2013-11-04  5:38 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-03 18:38 [RFC][PATCH] BTRFS_PROG: mount.btrfs helper Goffredo Baroncelli
2013-11-03 18:38 ` [PATCH] Provide " Goffredo Baroncelli
2013-11-03 21:23 ` Jeff Mahoney [this message]
2013-11-03 23:07   ` [RFC][PATCH] BTRFS_PROG: " Goffredo Baroncelli

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=5276BED4.4060707@suse.com \
    --to=jeffm@suse.com \
    --cc=kreijack@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    /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).