Re: [PATCH 0/6] btrfs-progs: New 'lost+found' infrastructrue with

[Qu Wenruo <quwenruo@cn.fujitsu.com>]

-------- Original Message --------
Subject: Re: [PATCH 0/6] btrfs-progs: New 'lost+found' infrastructrue with
From: David Sterba <dsterba@suse.cz>
To: Qu Wenruo <quwenruo@cn.fujitsu.com>
Date: 2014年11月26日 02:32
> On Mon, Nov 24, 2014 at 05:06:59PM +0800, Qu Wenruo wrote:
>> Introduce the new 'lost+found' dir and related infrastructure to create it
>> in btrfs-progs.
>>
>> [BUG]
>> With the new infrastructure, fix a bug that some people reported in both
>> kernel BZ and maillist, which there is some files' nlink is 1 but backref
>> points to non-exist parent.
>> The two reporters all report missing file(chrome config file), so we'd
>> better not to delete such files but use the 'lost+found' dir.
> Well, I don't like introducing the lost+found directory.
>
> My idea is to extend the rescue utilities to extract the unlinked and
> copy them to a user defined directory and do not touch the filesystem.
Personally, also mentioned by others (maybe Chris?), I think btrfs 
should only have two fsck facilities:
btrfsck for offline check and recovery, and scrub for online check and 
recovery.

So rescue may finally be merged into btrfsck and extending rescue may 
not be a good idea.

Also, such nlink mismatch is not such a huge bug destroying the whole fs 
or making it unable to mount,
end users may not be happy with the fact they need to extra command 
other than btrfsck to fix such
a small problem.
>
> Or, at least make the in-filesytem lost+found directory creation
> optional.
This seems better, but when user gives '--repair' option, they should be 
aware of the fact that the fs
maybe modified by btrfsck.

Still your idea about optional creation of 'lost+found' dir is indeed 
important for end users,
just like e2fsck's annoying but solid prompt.

What about try to prompt user that we are going to modify the fs and ask 
for y/n ?
> You've split the patches well so I'm going to pull 1-5
> directly. Patch 6 should be updated a bit, I'll look closer and will let
> you know.
0004 and 0005 have some small fixes, I'll send the v2 patches soon.

Thanks,
Qu
>
>> 2. Unify the repair framework.
>> When writing the 6th patch, I think it is better to build a frame work
>> that unify the check and repair framework.
>> In 6th patch, my patchset and Josef's commit 2dc4c001 in fact has some
>> similar function but do the repair in different time and functions.
>>
>> I will try to build a unified framework for repair, each repair will be
>> independent and have its own err number.
>> And each repair function should work like the following:
>> 1) Check the error number
>> 2) Do the repair
>> 3) Update the related btrfsck record(like newly created inode, deleted inode)
> The unification is most welcome, feel free to send me anything that could be
> merged as preparatory work (cleanups, safe changes, etc).