Hi Daniel,
With your btrfs-image dump, I tested with my patchset sent to maillist,
my patchset succeeds fixing the image.
You can get the patchset and then apply it on 3.17.2, and --repair
should fix it.
The file with nlink error will be moved to 'lost+found' dir.
Although the best fixing should be just adding the missing dir_index,
but currently the patchset does quite well and does not need to do any
modify.
The patchset can be extracted using patchwork:
0001: https://patchwork.kernel.org/patch/5364131/mbox/
0002: https://patchwork.kernel.org/patch/5364141/mbox/
0003: https://patchwork.kernel.org/patch/5364101/mbox/
0004 v2: https://patchwork.kernel.org/patch/5383611/mbox/
0005 v2: https://patchwork.kernel.org/patch/5383601/mbox/
0006: https://patchwork.kernel.org/patch/5364151/mbox
Any feedback is welcomed to improve the patches.
Thanks,
Qu
-------- Original Message --------
Subject: Re: Apparent metadata corruption (file that simultaneously
does/does not exist) on kernel 3.17.3
From: Daniel Miranda <danielk...@gmail.com>
To: Qu Wenruo <quwen...@cn.fujitsu.com>
Date: 2014年11月25日 15:42
I just ran the repair but the ghost file has not disappeared, unfortunately.
On Tue, Nov 25, 2014 at 5:26 AM, Qu Wenruo <quwen...@cn.fujitsu.com> wrote:
-------- Original Message --------
Subject: Re: Apparent metadata corruption (file that simultaneously
does/does not exist) on kernel 3.17.3
From: Daniel Miranda <danielk...@gmail.com>
To: Qu Wenruo <quwen...@cn.fujitsu.com>
Date: 2014年11月25日 15:20
Here are the logs. I'll send you a link to my dump directly after I
finish uploading it. Please notify me when you have downloaded it so I
can delete it.
checking extents
checking free space cache
checking fs roots
root 5 inode 17149868 errors 2000, link count wrong
unresolved ref dir 17182377 index 245 namelen 8 name string.h
filetype 1 errors 1, no dir item
link count error seems resolved by Josef's patch commit already in 3.17.2.
If using 3.17.2, josef's commit will rebuild the dir item and dir index.
root 5 inode 17182377 errors 200, dir isize wrong
This isize error seems caused by previous line.
If 3.17.2 can repair above problem, it should not be a problem and will
disappear.
According to the above output, btrfsck --repair with btrfs-progs 3.17.2 has
a good chance repairing it.
Just have a try.
Thanks,
Qu
Checking filesystem on /dev/mapper/fedora_daniel--pc-root
UUID: fef8f718-0622-4cb1-9597-749650d366a4
found 55108022156 bytes used err is 1
total csum bytes: 89787396
total tree bytes: 2303455232
total fs tree bytes: 2024841216
total extent tree bytes: 145272832
btree space waste bytes: 529672422
file data blocks allocated: 253414481920
referenced 94127726592
Btrfs v3.17
Regards,
Daniel
On Tue, Nov 25, 2014 at 3:20 AM, Qu Wenruo <quwen...@cn.fujitsu.com>
wrote:
-------- Original Message --------
Subject: Re: Apparent metadata corruption (file that simultaneously
does/does not exist) on kernel 3.17.3
From: Daniel Miranda <danielk...@gmail.com>
To: Qu Wenruo <quwen...@cn.fujitsu.com>
Date: 2014年11月25日 13:14
I'll go run that and get you the output.
Thanks.
I can do the image dump, sure. I don't know how long it might take to
upload it somewhere though. Right now `btrfs fi df` shows about 2GiB
of metadata (it's a 120GiB volume). I'll see how large it ends up
after compression.
120G volume seems quite small, compared the images I received recently
(1T
x2 RAID1 and 4T single).
With '-c 9' it shouldn't be too huge I think(The 1T raid1 is about 1G
metadata with -c9).
BTW, btrfs-image dump will have all the filenames and hierarchy, even
without its data,
it is still better considering your privacy twice before uploading.
Thanks,
Qu
Thanks for the quick response,
Daniel
On Tue, Nov 25, 2014 at 3:10 AM, Qu Wenruo <quwen...@cn.fujitsu.com>
wrote:
Hi,
What's the btrfsck output? Without --repair option.
Also, if it is OK for you, would you please dump the btrfs with
'btrfs-image' command?
'-c 9' option is highly recommended considering the size of it.
This will helps a lot for developers to test the btrfsck repair
function.
Thanks,
Qu
-------- Original Message --------
Subject: Apparent metadata corruption (file that simultaneously
does/does
not exist) on kernel 3.17.3
From: Daniel Miranda <danielk...@gmail.com>
To: <linux-btrfs@vger.kernel.org>
Date: 2014年11月25日 13:04
Hello,
After I had some brief stability issues with my computer, it seems
some form of metadata corruption took place in my BTRFS filesystem,
and now a particular file seems to exist, but I cannot access any
details on it or delete it.
If I try to `ls` in the directory it is in, that's what I get:
ls: cannot access string.h: No such file or directory
total 0
drwxr-xr-x. 1 danielkza mock 16 Nov 21 14:18 ./
drwxr-xr-x. 1 danielkza mock 6 Nov 21 14:18 ../
-?????????? ? ? ? ? ? string.h
If I try to delete it I get:
rm: cannot remove ‘string.h’: No such file or directory
I'm using kernel 3.17.3 from Fedora 21. I got no messages on dmesg or
anything of the sort. I know the btrfs fsck situation is complicated,
but is there any utility I should use to try and repair this? Losing
this file is not a problem, it's just one header from the kernel I was
building.
Regards,
Daniel Miranda
--
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
