lkml.org 
[lkml]   [1999]   [Jan]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: scary ext2 filesystem question
From
Date
"Theodore Y. Ts'o" <tytso@MIT.EDU> writes:

> 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/

\
 
 \ /
  Last update: 2005-03-22 13:49    [from the cache]
©2003-2011 Jasper Spaans