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.
--
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

Reply via email to