All of lore.kernel.org
 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 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.