All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo@cn.fujitsu.com>
To: Daniel Miranda <danielkza2@gmail.com>
Cc: <linux-btrfs@vger.kernel.org>
Subject: Re: Apparent metadata corruption (file that simultaneously does/does not exist) on kernel 3.17.3
Date: Tue, 25 Nov 2014 13:20:51 +0800	[thread overview]
Message-ID: <547411B3.2040309@cn.fujitsu.com> (raw)
In-Reply-To: <CAPRQymNp3+387P-nmXKoWGNV31TKaYLBWv6g63WwJPqN4g-fYg@mail.gmail.com>


-------- Original Message --------
Subject: Re: Apparent metadata corruption (file that simultaneously 
does/does not exist) on kernel 3.17.3
From: Daniel Miranda <danielkza2@gmail.com>
To: Qu Wenruo <quwenruo@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 <quwenruo@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 <danielkza2@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 majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>


  reply	other threads:[~2014-11-25  5:20 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-25  5:04 Apparent metadata corruption (file that simultaneously does/does not exist) on kernel 3.17.3 Daniel Miranda
2014-11-25  5:10 ` Qu Wenruo
2014-11-25  5:14   ` Daniel Miranda
2014-11-25  5:20     ` Qu Wenruo [this message]
2014-11-25  7:20       ` Daniel Miranda
2014-11-25  7:26         ` Qu Wenruo
2014-11-25  7:42           ` Daniel Miranda
2014-11-26  2:41             ` Qu Wenruo
2014-11-26  3:07               ` Daniel Miranda
2014-12-03 12:50                 ` Daniel Miranda

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=547411B3.2040309@cn.fujitsu.com \
    --to=quwenruo@cn.fujitsu.com \
    --cc=danielkza2@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.