User: Password:
Subscribe / Log in / New account

Whither btrfsck?

Whither btrfsck?

Posted Oct 11, 2011 19:06 UTC (Tue) by raven667 (subscriber, #5198)
In reply to: Whither btrfsck? by maniax
Parent article: Whither btrfsck?

I have to agree with you on this one and disagree with our intrepid editor. The best time to release the fsck tool would have been a couple of years ago when the filesystem itself was in its eating babies stage and both could have matured together. As it is maybe it would be better to reduce the scope of the tool, instead of trying to comprehensively detect and fix any possible type of corruption, only fix what can be done robustly. You could add in new checks and fixes bit by bit depending on what kinds of corruption are ran into in production use.

Hmm, brainstorming for a minute how about taking another tack with the fsck tool entirely, have it leave the corrupt filesystem unmodified and write entirely new metadata on an external block device that can be used to recover data in extreme situations. Better that then nothing.

(Log in to post comments)

Whither btrfsck?

Posted Oct 11, 2011 19:56 UTC (Tue) by DiegoCG (guest, #9198) [Link]

I'm more worried about the lack of updates to the rest of the btrfs tools. Scrubbing, per file/directory COW and compression and read-only snapshots are available in the mainline fs code, but the corresponding changes to the btrfs tool have not been merged...

Whither btrfsck?

Posted Oct 11, 2011 19:57 UTC (Tue) by DiegoCG (guest, #9198) [Link]

(oops, I replied to the wrong message)

Whither btrfsck?

Posted Oct 11, 2011 22:37 UTC (Tue) by terryburton (subscriber, #26261) [Link]

On more that one occasion I have performed recoveries on corrupt filesystems of multi-user *nix boxes. (Think of Computer Science students keen to explore the latest kernel exploits against a teaching/research box...)

In severe circumstances the safest approach is usually to image the damaged filesystem to a different host, restore the live system from a trusted backup, let the users back in, then to perform the actual data recovery offline (fsck + debugfs) - restoring only the recovered content that users actually request or is full trusted (e.g. file checksums in btrfs.) This balances the need for access to fresh data against the risk of rouge data appearing into other users' files or latent corruption remaining in the recovered filesystem that may result in future data loss or crashes.

For the more routine, periodic checks that should be performed online (check interval expired, mount count exceeded, etc.) you had better trust your tools.

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds