All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: L A Walsh <xfs@tlinx.org>, linux-xfs@vger.kernel.org
Subject: Re: allow mounting w/crc-checking disabled? (was Re: filesystem dead, xfs_repair won't help)
Date: Mon, 10 Apr 2017 11:01:47 -0500	[thread overview]
Message-ID: <8b9b764e-8fb5-af30-f135-be51b6a67558@sandeen.net> (raw)
In-Reply-To: <58EB53CA.7030608@tlinx.org>

On 4/10/17 4:43 AM, L A Walsh wrote:
> Avi Kivity wrote:
>> Today my kernel complained that in memory metadata is corrupt and
>> asked that I run xfs_repair.  But xfs_repair doesn't like the
>> superblock and isn't able to find a secondary superblock.
>>   
> Why doesn't xfs have an option to mount with metadata checksumming
> disabled so people can recover their data?

Because if checksums are bad, your metadata is almost certainly bad,
and with bad metadata, you're not going to be recovering data either.

(and FWIW, CRCs are only the first line of defense: structure verifiers
come after that.  The chance of a CRC being bad and everything else
checking out is extremely small.)

> Seems like it should be easy to provide, no?
> 
> Or rather, if a disk is created with the crc option, is it possible
> to later switch it off or mount it without with checking disabled?

It is not possible.

> Yes, I know the mantra is that they should have had backups, but
> in practice it's seems not the case in a majority of uses outside
> of enterprise usage.  It sure seems that disabling a particular file
> or directory (if necessary) affected by a bad-crc, would be
> preferable to losing the whole disk.  That said, how many crc
> errors would be likely to make things unreadable or inaccessible?

How log is a piece of string?  ;)  Totally depends on the details.

> Given that the default before crc-checking was that the disks
> were still usable (often with no error being flagged or noticed),

Before, we had a lot of ad-hoc checks (or not.)  Many of those checks,
and/or IO errors when trying to read garbage metadata, would also
shut down the filesystem.

Proceeding with mutilated metadata is almost never a good thing.
You'll wander off into garbage and shut down the fs at best, and OOPS
at worst.  (Losing a filesystem is preferable to losing a system!)

> I'd suspect that the crc-checking is causing many errors to be
> be flagged that before wouldn't have even been noticed.

Yes, that's precisely the point of CRCs.  :)

> Overall I'm wondering if the crc option won't cause more disk-losses
> than would occur without the option.  Or, in other words, it seems
> that since crc-checking seems to cause the disk to be lost, turning
> on crc checking is almost guaranteed to cause a higher incidence of
> data loss if it can't be disable.

When CRCs detect metadata corruption, the next step is to run
xfs_repair to salvage what can be salvaged, and retrieve what's left of
your data after that.  Disabling CRCs and proceeding in kernelspace with
known metadata corruption would be a dangerous total crapshoot.

-Eric

  reply	other threads:[~2017-04-10 16:01 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-10  9:23 filesystem dead, xfs_repair won't help Avi Kivity
2017-04-10  9:42 ` Avi Kivity
2017-04-10 15:35   ` Brian Foster
2017-04-11  7:46     ` Avi Kivity
2017-04-11 11:30       ` Emmanuel Florac
2017-04-11 11:40         ` Avi Kivity
2017-04-11 12:00           ` Emmanuel Florac
2017-04-11 12:03             ` Avi Kivity
2017-04-11 12:49               ` Emmanuel Florac
2017-04-11 13:07                 ` Avi Kivity
2017-04-11 16:13                   ` Emmanuel Florac
2017-04-11 16:44                     ` Avi Kivity
2017-04-11 16:48                       ` Eric Sandeen
2017-04-12 15:15                         ` Christoph Hellwig
2017-04-12 15:34                           ` Eric Sandeen
2017-04-12 15:45                             ` Christoph Hellwig
2017-04-12 16:15                               ` Avi Kivity
2017-04-12 16:20                                 ` Christoph Hellwig
2017-04-12 16:22                                   ` Eric Sandeen
2017-04-12 16:24                                     ` Avi Kivity
2017-04-12 16:22                                   ` Avi Kivity
2017-04-12 17:41                                     ` Christoph Hellwig
2017-04-10  9:43 ` allow mounting w/crc-checking disabled? (was Re: filesystem dead, xfs_repair won't help) L A Walsh
2017-04-10 16:01   ` Eric Sandeen [this message]
2017-04-10 18:05     ` L A Walsh
2017-04-11 12:57       ` Emmanuel Florac
2017-04-11 13:34         ` Eric Sandeen
2017-04-11 16:18           ` Emmanuel Florac
2017-04-11 16:34             ` Eric Sandeen
2017-04-10 15:49 ` filesystem dead, xfs_repair won't help Eric Sandeen
2017-04-10 16:23   ` Christoph Hellwig
2017-04-11  7:48   ` Avi Kivity

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=8b9b764e-8fb5-af30-f135-be51b6a67558@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=linux-xfs@vger.kernel.org \
    --cc=xfs@tlinx.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.