Re: allow mounting w/crc-checking disabled? (was Re: filesystem dead, xfs_repair won't help)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 4/11/17 7:57 AM, Emmanuel Florac wrote:
> Le Mon, 10 Apr 2017 11:05:38 -0700
> L A Walsh <xfs@xxxxxxxxx> écrivait:
> 
>> 	I'm sure it wouldn't be trivial, but creating a separate
>> file system, "XFS2" from the original XFS sources that responded
>> to data or metadata corruption by returning empty data where
>> it was impossible to return anything useful instead of flagging
>> the disk as "bad", would be a way to allow data recovery to
>> the extent that it made sense (assuming the original sources
>> couldn't do the same toggling off a config-flag).
> 
> It would probably much easier to add an option to mount the filesystem
> without crc, similar to "norecovery", that doesn't replay the journal.
> It would be of course read-only, but in a similar case it would be much
> easier and practical for everyone.

Yes, I actually whipped up a patch to do just that, because I was curious.
Although I don't think it would fly, I may send it just to have
a record out on the list.

> So far I believed that metadata CRCs were a promise of safer
> filesystems; now that I've setup several multi-hundred terabytes
> volumes with CRC enabled, I'm getting nervous...

Why?

So far there's a lot of fear & speculation from some quarters, but no
reports of any actual real-world significant downside to CRC integrity
checking.

A few amendments to my possibly too-quick reply yesterday, though...

One, not every CRC error will shut down your filesystem - far from it.
As a quick test of Linda's first scenario, you can corrupt a timestamp
without changing the CRC, using xfs_db's expert mode.  That inode
will be inaccessible until it's fixed with xfs_repair, but the filesystem
continues on happily.

Two, after talking with Darrick I realized that I misrepresented
things a bit; we checksum the entire sector of metadata, so yes,
even a bitflip in an unused portion of that location could cause
a crc mismatch and therefore a metadata read error.  But again, this would
render that data structure inaccessible until repair, but it would not take
the entire filesystem offline.

Three, none of this has anything to do with the email that started
this thread.  Bad firmware turned Avi's SSD into a vat of goo, and CRCs
are not in any way related to his inability to recover his filesystem.

Thanks,
-Eric

 

Attachment: signature.asc
Description: OpenPGP digital signature


[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux