Tweet
Beware those who say X is never needed.
I've trashed test BTRFS rigs with simple power failures during write. Having to restore several TB from backups is a good sign this is not ready for heavy production use.
Having a fsck which can't actually repair FS damage is a bit like having a bucket with a hole in it.
If someone says a filesystem doesn't need fsck because $bad_thing will never happen then alarm bells should be going off(*). If they say it shouldn't need one but here's one anyway you're in a much better position.
(*) DEC's AdvFS developers said that repeatedly. Until V5 shipped, AdvFS gathered a reputation as a FS which taught admins the value of regular backups.
On the other hand I have _never_ lost data from ZFS test systems short of simulating multidrive total failures in excess of the redundancy levels (and even then, if the "missing" drives are plugged back in and ZFS restarted, the FS recovered. It's even coped with buggy SATA controllers which dropped commands)
Originally posted by macemoneta
View Post
Having a fsck which can't actually repair FS damage is a bit like having a bucket with a hole in it.
If someone says a filesystem doesn't need fsck because $bad_thing will never happen then alarm bells should be going off(*). If they say it shouldn't need one but here's one anyway you're in a much better position.
(*) DEC's AdvFS developers said that repeatedly. Until V5 shipped, AdvFS gathered a reputation as a FS which taught admins the value of regular backups.
On the other hand I have _never_ lost data from ZFS test systems short of simulating multidrive total failures in excess of the redundancy levels (and even then, if the "missing" drives are plugged back in and ZFS restarted, the FS recovered. It's even coped with buggy SATA controllers which dropped commands)
Comment