Re: Is stability a joke? (wiki updated)

["Austin S. Hemmelgarn" <ahferroin7@gmail.com>]

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.