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. Or, at least make the in-filesytem lost+found directory creation optional. 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. > 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). -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
