All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo@cn.fujitsu.com>
To: Christoph Anton Mitterer <calestyo@scientia.net>,
	<linux-btrfs@vger.kernel.org>
Subject: Re: corruption: yet another one after deleting a ro snapshot
Date: Thu, 12 Jan 2017 09:25:40 +0800	[thread overview]
Message-ID: <a7b82ec9-bd8d-d6bb-27e7-3732b466ca06@cn.fujitsu.com> (raw)
In-Reply-To: <1484183243.10253.5.camel@scientia.net>



At 01/12/2017 09:07 AM, Christoph Anton Mitterer wrote:
> Hey.
>
> Linux heisenberg 4.8.0-2-amd64 #1 SMP Debian 4.8.15-2 (2017-01-04)
> x86_64 GNU/Linux
> btrfs-progs v4.7.3
>
> I've had this already at least once some year ago or so:
>
> I was doing backups (incremental via send/receive).
> After everything was copied, I unmounted the destination fs, made a
> fsck, all fine.
> Then I mounted it again and did nothing but deleting the old snapshot.
> After that, another fsck with the following errors:
>

According to the messages, some tree blocks has wrong extent backref.

And since you just deleted a subvolume and unmount it soon, I assume the 
btrfs is still doing background subvolume deletion, maybe it's just a 
false alert from btrfsck.

Would you please try btrfs check --mode=lowmem using latest btrfs-progs?

Sometimes bugs in original mode are fixed in lowmem mode.

And it's also recommended to call btrfs fi sync, then wait for some time 
(depending on the subvolume size) to allow btrfs to fully delete the 
subvolume, then try btrfsck.

Thanks,
Qu
>
> Usually I have quite positive experiences with btrfs (things seem to be
> fine even after a crash or accidental removal of the USB cable which
> attaches the HDD)... but I'm every time shocked again, when supposedly
> simple and basic operations like this cause such corruptions.
> Kinda gives one the feeling as if quite deep bugs are still everywhere
> in place, especially as such "hard to explain" errors happens every now
> and then (take e.g. my mails "strange btrfs deadlock", "csum errors
> during btrfs check" from the last days... and I don't seem to be the
> only one who suffers from such problems, even with the basic parts of
> btrfs which are considered to be stable - I mean we're not talking
> about RAID56 here)... sigh :-(
>
>
> While these files are precious, I have in total copies of all these
> files, 3 on btrfs and 1 on ext4 (just to be on the safe side if btrfs
> gets corrupted for no good reason :-( ).... so I could do some
> debugging here if some developer tells me what to do.
>
>
> Anyway... what should I do to repair the fs? Or is it better to simply
> re-create that backup from scratch?
>
>
> Cheers,
> Chris.
>



  parent reply	other threads:[~2017-01-12  1:25 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-12  1:07 corruption: yet another one after deleting a ro snapshot Christoph Anton Mitterer
2017-01-12  1:13 ` Christoph Anton Mitterer
2017-01-12  1:25 ` Qu Wenruo [this message]
2017-01-12  2:28   ` Christoph Anton Mitterer
2017-01-12  2:38     ` Qu Wenruo
2017-01-15 17:04       ` Christoph Anton Mitterer
2017-01-16  1:38         ` Qu Wenruo
2017-01-16  2:56           ` Christoph Anton Mitterer
2017-01-16  3:16             ` Qu Wenruo
2017-01-16  4:53               ` Christoph Anton Mitterer
2017-01-16  5:47                 ` Qu Wenruo
2017-01-16 22:07                   ` Christoph Anton Mitterer
2017-01-17  8:53                     ` Qu Wenruo
2017-01-17 10:39                       ` Christoph Anton Mitterer
2017-01-18  0:41                         ` Qu Wenruo
2017-01-18  1:20                           ` Christoph Anton Mitterer
2017-01-12 10:27 Giuseppe Della Bianca
2017-01-16 11:06 Giuseppe Della Bianca

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=a7b82ec9-bd8d-d6bb-27e7-3732b466ca06@cn.fujitsu.com \
    --to=quwenruo@cn.fujitsu.com \
    --cc=calestyo@scientia.net \
    --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.