From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cn.fujitsu.com ([59.151.112.132]:41645 "EHLO heian.cn.fujitsu.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1750836AbaKYFUx convert rfc822-to-8bit (ORCPT ); Tue, 25 Nov 2014 00:20:53 -0500 Message-ID: <547411B3.2040309@cn.fujitsu.com> Date: Tue, 25 Nov 2014 13:20:51 +0800 From: Qu Wenruo MIME-Version: 1.0 To: Daniel Miranda CC: Subject: Re: Apparent metadata corruption (file that simultaneously does/does not exist) on kernel 3.17.3 References: <54740F42.2040301@cn.fujitsu.com> In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Sender: linux-btrfs-owner@vger.kernel.org List-ID: -------- Original Message -------- Subject: Re: Apparent metadata corruption (file that simultaneously does/does not exist) on kernel 3.17.3 From: Daniel Miranda To: Qu Wenruo 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 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 >> To: >> 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 majordomo@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>