When i leverage the copyonwrite-ness (which is more redirect-on-write) of the filesystem to recover from a defunct state of the on-disk state to a known state, a filesystem check is just a suboptimal solution. That what i wanted to express with the article. Of course - most filesystems are not COW and can't use it, and thus the notion that a filesystem check is needed prevails. But at the end a filesystem check is just about forcing a filesystem into a state of metadata correctness, without caring much about the data. I wouldn't count that as a way out, when there are better ways.
I think the situation is pretty much similar to the "shoot the messenger" problem of ZFS. Some people are annoyed that ZFS reports errors because of corruption and blocks access to the data (of course without having any redundancy). However the alternative would be reading incorrect data. What's worse. Knowing that you have to recover data or processing incorrect data without knowing it.
I think the situation is pretty much similar to the "shoot the messenger" problem of ZFS. Some people are annoyed that ZFS reports errors because of corruption and blocks access to the data (of course without having any redundancy). However the alternative would be reading incorrect data. What's worse. Knowing that you have to recover data or processing incorrect data without knowing it.