linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: btrfs random filesystem corruption in kernel 3.17
Date: Tue, 14 Oct 2014 21:35:31 +0000 (UTC)	[thread overview]
Message-ID: <pan$67a58$c42f6156$af002a14$c1094f5a@cox.net> (raw)
In-Reply-To: c2103f1c229cdd887b8743d0946a8a8f@prnet.org

admin posted on Tue, 14 Oct 2014 13:17:41 +0200 as excerpted:

>> And if you're affected, be aware that until we have a fix, we don't
>> know if it'll be possible to remove the affected and currently
>> undeletable snapshots.  If it's not, at some point you'll need to do a
>> fresh mkfs.btrfs, to get rid of the damage.  Since the bug doesn't
>> appear to affect writable snapshots or the "head" from which snapshots
>> are made, it's not urgent, and a full fix is likely to include a patch
>> to detect and fix the problem as well, but until we know what the
>> problem is we can't be sure of that, so be prepared to do that mkfs at
>> some point, as at this point it's possible that's the only way you'll
>> be able to kill the corrupted snapshots.
> 
> I don't agree with you concerning the not urgent part. In my opinion,
> any problem leading to filesystem or other data corruption should be
> considered as urgent, at least as long as it isn't known what exactly is
> affected and whether there is a simple way to salvage the corruption
> without going the backup/restore route.

I shouldn't have used a pronoun there as "it" wasn't clear.

By "it", I didn't mean the bug, which I agree is urgent for the reasons 
you state, but the mkfs.  Since there's currently no fix for the bug but 
it (the bug) seems to be limited to read-only snapshots at this point, 
_doing_the_mkfs_ isn't urgent.  With the damage limited to the read-only 
snapshots, you don't have to drop everything and do a mkfs _right_now_ to 
be rid of it.

But at some point, presumably after a fix is in place, since the damaged 
snapshots aren't currently always deletable, if the fix only prevents new 
damage from occurring and doesn't provide a way to fix the damaged ones, 
then mkfs would be the only way to do so.  With the damage limited to 
those snapshots and not spreading to normal writable snapshots or the 
working copy, dropping everything to do that mkfs isn't urgent, but it 
(the mkfs) will need to be done at some point to clear the undeletable 
snapshots, again, assuming the fix doesn't provide a way to get rid of 
them (the currently undeletable snapshots).

That's what I meant.  Yes the bug is urgent.  Doing a mkfs _right_now_ to 
get rid of the damage, not so much, because by all accounts so far the 
damage is limited to those read-only snapshots and isn't affecting 
ordinary writable snapshots or the working copies.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


  reply	other threads:[~2014-10-14 21:35 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <DC336054-F307-4A86-AD6D-204E700DE9AA@prnet.org>
2014-10-07 13:19 ` btrfs send and kernel 3.17 Chris Mason
2014-10-07 20:45   ` David Arendt
2014-10-07 20:46     ` Chris Mason
2014-10-12 11:11       ` David Arendt
2014-10-12 15:24         ` john terragon
2014-10-12 21:35           ` David Arendt
2014-10-13  4:11             ` David Arendt
2014-10-13 12:40               ` john terragon
2014-10-13 15:40                 ` David Arendt
2014-10-13 17:22         ` Rich Freeman
2014-10-13 20:27           ` btrfs random filesystem corruption in " David Arendt
2014-10-13 20:42             ` Rich Freeman
2014-10-13 22:36               ` Duncan
2014-10-14 11:17                 ` admin
2014-10-14 21:35                   ` Duncan [this message]
2014-10-14 22:03                     ` Robert White
2014-10-14 22:55                       ` Duncan
2014-10-14 17:00                 ` David Arendt
2014-10-13 20:48             ` john terragon
2014-10-13 20:55               ` Rich Freeman
2014-10-13 20:57                 ` Rich Freeman
2014-10-13 21:22                 ` john terragon
2014-10-13 21:25                   ` David Arendt
2014-10-13 21:49                     ` Duncan
2014-10-13 23:18                   ` Rich Freeman
2014-10-14  1:30                     ` john terragon
2014-10-13 21:22               ` David Arendt

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='pan$67a58$c42f6156$af002a14$c1094f5a@cox.net' \
    --to=1i5t5.duncan@cox.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).