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
next prev parent 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 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.