Hello again, Sorry for the delay, I had some things to do this past week, including figuring out the stability problems that I was having, but everything is good now. I rebuilt the Fedora package for btrfs-progs 3.17.2 with your patches, and btrfsck successfully removed the orphan file! The contents seem to be intact in /lost+found. Thank you very much Qu, you've been immensily helpful.
Regards, Daniel On Wed, Nov 26, 2014 at 1:07 AM, Daniel Miranda <danielk...@gmail.com> wrote: > Alright, I'll just have to understand how to build btrfs-progs now, > since I'm currently just using the packages from the Fedora repo. > > Thanks for all the help and time spent so far, > Daniel > > > On Wed, Nov 26, 2014 at 12:41 AM, Qu Wenruo <quwen...@cn.fujitsu.com> wrote: >> 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
