On Fri, Sep 16, 2016 at 08:00:44AM -0400, Austin S. Hemmelgarn wrote: > To be entirely honest, both zero-log and super-recover could probably be > pretty easily integrated into btrfs check such that it detects when they > need to be run and does so. zero-log has a very well defined situation in > which it's absolutely needed (log tree corrupted such that it can't be > replayed), which is pretty easy to detect (the kernel obviously does so, > albeit by crashing).
Check already includes zero-log. It loses a little data that way, but that is probably better than the alternative (try to teach btrfs check how to replay the log tree and keep up with kernel changes). There have been at least two log-tree bugs (or, more accurately, bugs triggered while processing the log tree during mount) in the 3.x and 4.x kernels. The most recent I've encountered was in one of the 4.7-rc kernels. zero-log is certainly not obsolete. For a filesystem where availablity is more important than integrity (e.g. root filesystems) it's really handy to have zero-log as a separate tool without the huge overhead (and regression risk) of check.
signature.asc
Description: Digital signature
