On Fri, Dec 5, 2014 at 1:15 PM, Goffredo Baroncelli
<kreijack@xxxxxxxxx> wrote:
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..
Ok, these three things are worth improving, but I'd like to take a
slightly different direction. Instead of recreating chunks of btrfs
dev scan, lets extend btrfs dev scan to at the very least understand #1
and #2. As much as possible we want to be leveraging the data in udev
instead of recreating that functionality.
#3 is a slightly different feature, but we can have an extended btrfs
dev scan or show explain the state of the filesystem to you.
From there if we really need a mount helper, it can either use a
libbtrfs to hit the scan code or be a bash script.
Thanks for trying to smooth our or wrinkles in this area. It's
definitely worth working on, I just want to make sure we recreate as
little infrastructure as possible ;)
-chris
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
