Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Chris Mason <clm@fb.com>
To: Dimitri John Ledkov <xnox@debian.org>
Cc: cwillu <cwillu@cwillu.com>,
	"kreijack@inwind.it" <kreijack@inwind.it>,
	linux-btrfs <linux-btrfs@vger.kernel.org>,
	David Sterba <dsterba@suse.cz>,
	Zygo Blaxell <zblaxell@furryterror.org>
Subject: Re: [RFC][PATCH v2] mount.btrfs helper
Date: Fri, 5 Dec 2014 10:32:46 -0500	[thread overview]
Message-ID: <1417793566.21214.11@mail.thefacebook.com> (raw)
In-Reply-To: <CANBHLUhHktgJRYR5JDjPmvq=299iDR3xmwoPTjFh5ey7DnFxZw@mail.gmail.com>

On Sun, Nov 30, 2014 at 5:57 PM, Dimitri John Ledkov <xnox@debian.org> 
wrote:
> On 30 November 2014 at 22:31, cwillu <cwillu@cwillu.com> wrote:
>> 
>>  In ubuntu, the initfs runs a btrfs dev scan, which should catch
>>  anything that would be missed there.
>> 
> 
> I'm sorry, udev rule(s) is not sufficient in the initramfs-less case,
> as outlined.
> 
> In case of booting with initramfs, indeed, both Debian & Ubuntu
> include snippets there to run btrfs scan.

In an initramfs-less system, the root filesystem mount is done by the 
kernel, without calling any mount.btrfs.  The mount helper has all the 
same problems that calling btrfs dev scan does, it's just being run by 
mount.

I definitely agree that assembling the filesystem from userland is 
somewhat awkward, and people that don't want initrds end up needing to 
jump through hoops to get things done.

But, the tools we have to avoid the hoops are initrds and udev, and I'd 
much rather spend time fixing filesystem bugs than recreating those 
tools.  If people are having trouble with udev, or having trouble with 
tools in the initrd, lets contribute fixes to those projects instead.

For people that really really don't want initrds, pass the devices on 
the command line.  If that isn't working, we'll fix it, but if you 
really want a scan, please try an initrd.  You can even make one 
without any kernel modules, and then you don't have to recreate it 
until you want to update the userland in your initrd.

-chris




  parent reply	other threads:[~2014-12-05 15:33 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-30 17:43 [RFC][PATCH v2] mount.btrfs helper Goffredo Baroncelli
2014-11-30 22:11 ` Dimitri John Ledkov
2014-11-30 22:31   ` cwillu
2014-11-30 22:57     ` Dimitri John Ledkov
2014-11-30 23:27       ` cwillu
2014-12-05 15:32       ` Chris Mason [this message]
2014-12-05 16:01         ` Dimitri John Ledkov
2014-12-05 16:41           ` David Sterba
2014-12-05 18:15             ` Goffredo Baroncelli
2014-12-05 18:43               ` Chris Mason
2014-12-05 19:51                 ` Goffredo Baroncelli
2014-12-09 12:16                   ` David Sterba
2014-12-09 10:55                 ` David Sterba
2014-12-09 10:35           ` David Sterba
2014-12-04  2:09 ` Anand Jain
2014-12-04 17:58   ` Goffredo Baroncelli
2014-12-05  3:16     ` Anand Jain

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=1417793566.21214.11@mail.thefacebook.com \
    --to=clm@fb.com \
    --cc=cwillu@cwillu.com \
    --cc=dsterba@suse.cz \
    --cc=kreijack@inwind.it \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=xnox@debian.org \
    --cc=zblaxell@furryterror.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