Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Goffredo Baroncelli <kreijack@inwind.it>
To: dsterba@suse.cz, Dimitri John Ledkov <xnox@debian.org>,
	Chris Mason <clm@fb.com>, cwillu <cwillu@cwillu.com>,
	linux-btrfs <linux-btrfs@vger.kernel.org>,
	Zygo Blaxell <zblaxell@furryterror.org>
Subject: Re: [RFC][PATCH v2] mount.btrfs helper
Date: Fri, 05 Dec 2014 19:15:51 +0100	[thread overview]
Message-ID: <5481F657.8090307@inwind.it> (raw)
In-Reply-To: <20141205164144.GK9754@suse.cz>

On 12/05/2014 05:41 PM, David Sterba wrote:
> We're looking
> for good reasons to justify the existence of the helper, but this is
> still not enough IMHO. I can see the convenience to do it automatically,
> but this assumes no udev available which is probably rare these days.

I have the following reasons to support a mount.btrfs helper:
1) it is in a good point to check that everything is ok (see the thread
related LVM snapshot, due to a dev.uuid conflicts), 
2) it is in a good point to issue a good error explanation (missing 
device....)
3) it may handle case like "degraded" mode, where the filesystem is not
fully functional but even as degraded have "some" functionals..


On 12/05/2014 04:32 PM, Chris Mason wrote:
> 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.

Chris, I am bit confused by your answer: mount.btrfs helper is not 
a solution for the initrd-less system (whom I am not a fan 
anymore [*]). And I don't think that the awkward-ness of btrfs is due to
udev deficiencies.
Btrfs is new because acts both as filesystem and as dm/md layer. We 
know that there are very good reasons to do that. But also it
highlights new problems whom the old tools may be not a right solution.

See this from another point of view: md/dm have specific tools to
assemble the disks. So why btrfs wouldn't need a specific tool?

BR
G.Baroncelli


[*] I hope to not start another flame-war. I am not against to the 
initrd-less system; but if you want a multidevice filesystem (with 
or without md/dm) simply you cannot rely to the kernel only (IMHO).

-- 
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5

  reply	other threads:[~2014-12-05 18:15 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
2014-12-05 16:01         ` Dimitri John Ledkov
2014-12-05 16:41           ` David Sterba
2014-12-05 18:15             ` Goffredo Baroncelli [this message]
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=5481F657.8090307@inwind.it \
    --to=kreijack@inwind.it \
    --cc=clm@fb.com \
    --cc=cwillu@cwillu.com \
    --cc=dsterba@suse.cz \
    --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