Re: [PATCH v7 1/2] btrfs: Introduce "rescue=" mount option

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2072 bytes --]



On 2020/6/8 下午4:11, Anand Jain wrote:
> On 5/6/20 7:36 pm, David Sterba wrote:
>> On Fri, Jun 05, 2020 at 06:04:01PM +0800, Anand Jain wrote:
>>> On 4/6/20 3:18 pm, Qu Wenruo wrote:
>>>> This patch introduces a new "rescue=" mount option group for all those
>>>> mount options for data recovery.
>>>>
>>>> Different rescue sub options are seperated by ':'. E.g
>>>> "ro,rescue=nologreplay:usebackuproot".
>>>> (The original plan is to use ';', but ';' needs to be escaped/quoted,
>>>> or it will be interpreted by bash)
>>>
>>>    I fell ':' isn't suitable here.
>>
>> What do you suggest then?
>>
> 
> There isn't any other choice, right? Probably that's the reason for
> -o device it is -o device=dev1,device=dev2 still remains separated?
> IMO if there isn't a choice it is ok to leave them separate.
> 
> But as I commented in the other thread instead of
> -o rescue=skipbg:another1:another2 why not just -o rescue
> and mount thread shall skip the checks that fail and mount the
> fs in RO if possible.

That would make dependency complex. The skipbg already needs nologreplay
and RO, and usebackuproot sometimes doesn't work as expected (in fact,
that mount option has fewer success than we thought).

I don't want to spend too much code on a salvage mount option group.

Thanks,
Qu

> The dmesg -k must show the checks that
> were failed and had to skip to make the RO mount successful.
> So, that becomes clear about the errors which lead to the current RO
> mount, instead of going through the logs to figure out. This is a more
> user-friendly approach as there is one rescue option. But I am not
> sure if it is possible?
> 
> Thanks, Anand
> 
> 
>>>> And obviously, user can specify rescue options one by one like:
>>>> "ro,rescue=nologreplay,rescue=usebackuproot"
>>>
>>>    This should suffice right?
>>
>> Setting the rescue= value separately should be supported, but requiring
>> to write the option name for each value defeats the purpose to make it
>> compact and user friendly.
>>
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]