On Thursday 26 May 2005 02:05, Hans Reiser reiser@namesys.com wrote:
Finally, are there still known situations where a corrupt ReiserFS file
They were reported years ago on the ReiserFS list. Hans didn't seem inclined to fix them as fixing such bugs incurred a performance penalty.
If that policy has changed in the ReiserFS development team then I'll write some scripts to randomly corrupt ReiserFS file systems and try to reproduce kernel bugs.
I don't know which bugs you are referring to, and I don't remember saying what you ascribe to me. Perhaps you refer to my not fscking each node after it is read into memory before it is used by the filesystem. I don't think anybody does that, not just us. Some checks are made by us, but a complete and exhaustive check is not made by anyone that I know of. We could probably write a node plugin that would crc check after the node is read from disk. That would be reasonable, and I would accept a node plugin to do that.
I don't know the exact cause of the bug in terms of which part of the code was responsible.
I reported a bug where I had a file system which if mounted would have a "find /" operation cause a kernel Oops. As far as I am aware the bug in question was never fixed.
It is my belief and the belief of many other people that a corrupted file system should not be able to corrupt kernel memory, not even if the file system is maliciously generated (think about the case of an attacker inserting a CD or USB disk). I am not aware of any other Linux file system for which a corrupted partition can cause kernel memory corruption (please inform me if you know of one).
As for the "complete and exhaustive check", maybe this is an advantage for a file system based on Inode tables as the data structures are simpler and easier to check?