Re: [RFC][PATCH v2] mount.btrfs helper

[Chris Mason <clm@fb.com>]

On Fri, Dec 5, 2014 at 1:15 PM, Goffredo Baroncelli 
<kreijack@inwind.it> 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