3 ms·

The basic problem of filesystem repair is the point that you repair the metadata, but it can do nothing about your data. So when your filesystem enables you to

The basic problem of filesystem repair is the point that you repair the metadata, but it can do nothing about your data. So when your filesystem enables you to fall back to a known consistent state of metadata and data by the COW, you should fall back to a known consistent state. And not to something that is repaired by a generic tool. How do you know in such a situation that somewhere in you thousands and thousands of files the repair got something wrong. The copy on write behaviour of ZFS has it's advantages. And as i already wrote in a different comment: If there is a bug in the stuff writing the on-disk state, the bug should be addressed on the exact knowledge of the bug in the code reading the on-disk-state and thus doesn't make assumption what could be halfway correct, but by some piece of code that does the correct with the incorrect on-disk-state.

jodrellblank 14y ago
Yes, I know you said both those two things, and I agree - ZFS has inbuilt error detection and healing. Any code that can detect errors and heal them should be there. And if you have corruption the only long term, safe, ass-covering advice to give is to restore to a pre-corrupt state. But the argument went: Detractor: ZFS needs fsck. You: No it doesn't. Detractor: ZFS creators attitude has always been "we don't think it should exist", but there's no more reason than this. It still corrupts so it still needs an fsck tool. You: Here is a big blog post about why it doesn't: OK so it can get corrupted but I don't think an fsck tool should exist. You know how useful it is to post on StackExchange "help I have this situation, I know conceptually there is a way out, but how can I actually do it?" and get the replies "you shouldn't want to do that"? It's not helpful at all.
- c0t0d0s0 14y ago
  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.

jodrellblank 14y ago

Yes, I know you said both those two things, and I agree - ZFS has inbuilt error detection and healing. Any code that can detect errors and heal them should be there. And if you have corruption the only long term, safe, ass-covering advice to give is to restore to a pre-corrupt state. But the argument went: Detractor: ZFS needs fsck. You: No it doesn't. Detractor: ZFS creators attitude has always been "we don't think it should exist", but there's no more reason than this. It still corrupts so it still needs an fsck tool. You: Here is a big blog post about why it doesn't: OK so it can get corrupted but I don't think an fsck tool should exist. You know how useful it is to post on StackExchange "help I have this situation, I know conceptually there is a way out, but how can I actually do it?" and get the replies "you shouldn't want to do that"? It's not helpful at all.

c0t0d0s0 14y ago
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.