On 2016-09-18 22:57, Zygo Blaxell wrote:
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).
Interesting, as I've never seen check try to zero the log (even in cases
where it would fix things) unless it makes some other change in the FS.
I won't dispute that it clears the log tree _if_ it makes other changes
to the FS (it kind of has to for safety reasons), but that's the only
circumstance that I've seen it do so (even on filesystems where the log
tree was corrupted, but the rest of the FS was fine).
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.
I won't dispute this, as I've had it happen myself (albeit not quite
that recently), all I was trying to say was that it fixes a very well
defined problem.
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.
Agreed, hence my later statement that if it gets fully merged, there
should be an option to run just that.
--
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
