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
next prev parent 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).