All of lore.kernel.org
 help / color / mirror / Atom feed
From: L A Walsh <xfs@tlinx.org>
To: linux-xfs@vger.kernel.org
Subject: allow mounting w/crc-checking disabled?  (was Re: filesystem dead, xfs_repair won't help)
Date: Mon, 10 Apr 2017 02:43:38 -0700	[thread overview]
Message-ID: <58EB53CA.7030608@tlinx.org> (raw)
In-Reply-To: <CAF950WLvp7SWnDHU_AY+j3CYtCDWYLdN=AkNZgNB2yU3sVxsJQ@mail.gmail.com>

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?

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?

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?
Given that the default before crc-checking was that the disks
were still usable (often with no error being flagged or noticed),
I'd suspect that the crc-checking is causing many errors to be
be flagged that before wouldn't have even been noticed. 

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. 




  parent reply	other threads:[~2017-04-10 10:13 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 ` L A Walsh [this message]
2017-04-10 16:01   ` allow mounting w/crc-checking disabled? (was Re: filesystem dead, xfs_repair won't help) Eric Sandeen
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=58EB53CA.7030608@tlinx.org \
    --to=xfs@tlinx.org \
    --cc=linux-xfs@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.