Re: Is stability a joke? (wiki updated)

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

On 2016-09-15 17:23, Christoph Anton Mitterer wrote:
> On Thu, 2016-09-15 at 14:20 -0400, Austin S. Hemmelgarn wrote:
>> 3. Fsck should be needed only for un-mountable filesystems.  Ideally,
>> we
>> should be handling things like Windows does.  Preform slightly
>> better
>> checking when reading data, and if we see an error, flag the
>> filesystem
>> for expensive repair on the next mount.
>
> That philosophy also has some drawbacks:
> - The user doesn't directly that anything went wrong. Thus errors may
> even continue to accumulate and getting much worse if the fs would have
> immediately gone ro and giving the user the chance to manually
> intervene (possibly then with help from upstream).
Except that the fsck implementation in windows for NTFS actually fixes 
things that are broken.  MS policy is 'if chkdsk can't fix it, you need 
to just reinstall and restore from backups'.  They don't beat around the 
bush trying to figure out what exactly went wrong, because 99% of the 
time on Windows a corrupted filesystem means broken hardware or a virus. 
  BTRFS obviously isn't to that point yet, but it has the potential if 
we were to start focusing on fixing stuff that's broken instead of 
working on shiny new features that will inevitably make everything else 
harder to debug, we could probably get there faster than most other 
Linux filesystems.
>
> - Any smart auto-magical™ repair may also just fail (and make things
> worse, as the current --repair e.g. may). Not performing such auto-
> repair, gives the user at least the possible chance to make a bitwise
> copy of the whole fs, before trying any rescue operations.
> This wouldn't be the case, if the user never noticed that something
> happen, and the fs tries to repair things right at mounting.
People talk about it being dangerous, but I have yet to see it break a 
filesystem that wasn't already in a state that in XFS or ext4 would be 
considered broken beyond repair.  For pretty much all of the common 
cases (orphaned inodes, dangling hardlinks, isize mismatches, etc), it 
does fix things correctly.  Most of that stuff could be optionally 
checked at mount and fixed without causing issues, but it's not 
something that should be done all the time since it's expensive, hence 
me suggesting checking such things dynamically on-access and flagging 
them for cleanup next mount.
>
> So I think any such auto-repair should be used with extreme caution and
> only in those cases where one is absolutely a 100% sure that the action
> will help and just do good.
In general, I agree with this, and I'd say it should be opt-in, not 
mandatory.  I'm not talking about doing things that are all that risky 
though, but things which btrfs check can handle safely.