On Mon, Sep 19, 2016 at 12:08:55AM -0400, Zygo Blaxell wrote: > <snip> > At the end of the day I'm not sure fsck really matters. If the filesystem > is getting corrupted enough that both copies of metadata are broken, > there's something fundamentally wrong with that setup (hardware bugs, > software bugs, bad RAM, etc) and it's just going to keep slowly eating > more data until the underlying problem is fixed, and there's no guarantee > that a repair is going to restore data correctly. If we exclude broken > hardware, the only thing btrfs check is going to repair is btrfs kernel > bugs...and in that case, why would we expect btrfs check to have fewer > bugs than the filesystem itself?
I see btrfs check as having a very useful role: fixing known problems introduced by previous versions of kernel / progs. In my ext conversion thread, I seem to have discovered a problem introduced by convert, balance, or defrag. The data and metadata seem to be OK, however the filesystem cannot be written to without btrfs falling over. If this was caused by some edge-case data in the btrfs partition, it makes a lot more sense to have btrfs check repair it than it does to modify the kernel code to work around this and possibly many other bugs. The upshot to this is that since (potentially all of) the data is intact, a functional btrfs check would save me the hassle of restoring from backup. --Sean -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
