-------- Original Message --------
Subject: Re: [PATCH 0/6] More generic inode nlink repair function
From: Satoru Takeuchi <takeuchi_sat...@jp.fujitsu.com>
To: Ed Tomlinson <e...@aei.ca>, <linux-btrfs@vger.kernel.org>
Date: 2014年12月03日 15:12
Hi,
(2014/12/03 14:03), Ed Tomlinson wrote:
Hi,
I'd really like to see these patches included in btrfsck - they
repaired my fs. Once
Qu got them working they found additional corruptions. This time
there was no crash or stall
just an umount that left (chromium) files unlinked... The bug with
these files has been
hitting me for a while - just did not recognize what was causing it
or notice the corruption.
The only objection I have seen to these patches is that they may
create a "lost+found"
directory. I submit this is an expected behavior for a fsck
utility. When --repair is specified
I expect a fsck to make changes to my fs one of which may be adding
and populating a
lost+found directory.
How about making lost+found on mkfs.btrfs like ext4?
Thanks,
Satoru
I hope most user won't see the lost+found dir.
Due to the COW feature especially on all the metadata,
btrfs is *supposed* to be fsck free and self repairing fs, make
lost+found at mkfs time
may make btrfs not so special among the old time ext* fs.
IMHO, most user will not see the lost+found dir, if hardware and kernel
works as they should be,
usual bit flip can be recovered by the default DUP or higher RAID
metadata profile.
The lost+found dir will only occur if the fs is really badly damaged or
kernel bug.
(or intently damaged by btrfs-corrupt-block for QA reason).
With the maturing of btrfs, such case should be more and more rare and
most user will forget
the fact that btrfsck will create lost+found dir, but it will still be
the last hope.
So lost+found should only occur when it is needed, and when it is needed
it will be created.
Thanks,
Qu
Thanks
Ed Tomlinson
PS. It would be very interesting to find out WHY these files are
ending up unlinked. Ideas?
On Wednesday 03 December 2014 12:18:26 you wrote:
Update on patch 4 and 6, other is not changed.
This nlink repair function is more generic than the original one.
The old one can only handle a specific case that the inode_ref is
invalid, either point to a non-exist parent inode or point to a invalid
inode(not dir or conflicting index/name).
The new one will reset all the backref, no matter it is valid or not,
and re-add all the valid backref, this make the nlink handles more
corrupt cases.
Qu Wenruo (6):
btrfs-progs: print root dir verbose error in fsck
btrfs-progs: Import btrfs_insert/del/lookup_extref() functions.
btrfs-progs: Import lookup/del_inode_ref() function.
btrfs-progs: Add btrfs_unlink() and btrfs_add_link() functions.
btrfs-progs: Add btrfs_mkdir() function for the incoming
'lost+found'
fsck mechanism.
btrfs-progs: Add fixing function for inodes whose nlink dismatch
Makefile | 2 +-
cmds-check.c | 311 ++++++++++++++++++++++++++++++++++++--
ctree.c | 6 +
ctree.h | 38 +++++
inode-item.c | 318 +++++++++++++++++++++++++++++++++++++++
inode.c | 484
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
6 files changed, 1148 insertions(+), 11 deletions(-)
create mode 100644 inode.c
--
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
--
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
--
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
