> Well, the confusing part is that fsck reports some size/count changes
> (I don't remember the exact error message right now), something like
> inode number x, was y, should be z, corrected. Now, if I write down
> that inode numbers, and find corresponding files after fsck finishes,
> they are in many cases corrupted (maybe in all cases?). I was always
> wondering, what would happen if fsck DID NOT repair the files. After
> all, it knows that older value.
>
> What likely happened is that part of the metadata (an indirect block,
> containing a block reference) got written out to disk, while another
> part of the metadata (the inode, containing the size of the file)
> didn't make it out to disk. In this case, e2fsck errs on the side of
> not losing data, which means that instead of throwing away the newly
> allocated block, it will expand the size field in the inode.
>
Thanks for a nice explanation. I thought it was something like that,
but wasn't sure. Now I see that ext2 is really as good as it can get.
Not that I doubted that before, but fsck was kind of suspicious to
me. :)
> Now, what that UPS can't do is prevent me from "improving" kernel
> sources and making mistakes along a way. If you by any chance get hold
> of a model with such functionality, please inform me fast where should
> I go and buy it. :)
>
> Well, you could simply not make mistakes. <grin>
>
:)
-- Zlatko- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/