| |||||||||||||
|
| |||||||||||||
CorrectnessCorrectnessPosted Dec 5, 2008 18:22 UTC (Fri) by man_ls (subscriber, #15091)In reply to: Correctness by ncm Parent article: Tux3: the other next-generation filesystem Everything you say can be prevented by a more robust filesystem with data journaling, even without checksums. Ext3 with data=ordered is an example. Even with checksumming data integrity is not guaranteed: yes, the filesystem will detect that a sector is corrupt, but it still needs to locate a good previous version and be able to roll back to that version. Isn't it easier to just do data journaling?
(Log in to post comments)
Correctness Posted Dec 5, 2008 22:18 UTC (Fri) by ncm (subscriber, #165) [Link] Everything you say can be prevented by a more robust filesystem ...FALSE. I'm talking about hardware-level sector failures. A filesystem without checksumming can be made robust against reported bad blocks, but a bad block that the drive delivers as good can completely bollix ext3 or any fs without its own checksums. Drive manufacturers specify and (just) meet a rate of such bad blocks, low enough for non-critical applications, and low enough not to kill performance of critical applications that perform their own checking and recovery methods. Denial is not a sound engineering practice.
Correctness Posted Dec 6, 2008 0:06 UTC (Sat) by man_ls (subscriber, #15091) [Link] Interesting point: it seems I misread your post so let me re-elaborate. Data journaling prevents against half-written sectors, since they will not count as written. This leaves a power-off which causes physical damage to a disk, and yet the disk will not realize the sector is bad. Keep in mind that we have data journaling, so this particular sector will not be used until it is completely overwritten. The kind of damage must be permanent yet remain hidden when writing, which is why I deemed it impossible. It seems you have good cause to believe it can happen, so it would be most enlightening to hear any data points you may have.As to your concerns about high data density and error rates, they are exactly what Mr Phillips happily dismisses: in practice they do not seem to cause any trouble. Over-engineering is not a sound engineering practice either.
Correctness Posted Dec 7, 2008 22:28 UTC (Sun) by ncm (subscriber, #165) [Link]
We have, elsewhere in this same thread, reports of bad data delivered as good, and causing trouble, Mr. Phillips's opinion notwithstanding. The incidence is, therefore, not negligible for data many people care about. Partially-written blocks are only one cause of bad sectors, which I noted only because they are an example on one that occurs much for frequently for some users than for others. Bad sectors may occur in the journal as well as in file contents. The drive will detect and report only a large, but not always a large enough, fraction of these.
|
|
||||||||||||