What happens when the ext3 inode tables get hit by sector damage? Like
us, ext3 has data munging if you hit the wrong thing, its just that our
sources of data munging are different in the details. Details matter
though, and so we are improving with each release, and V4 does have some
real improvements. I hope the next major release will have atomic
transactions that don't have that niggling 5% left undone that prevents
them from being fully there, and then reiser4 can seriously advance the
field of reliability in filesystems rather than just playing catchup.
Good luck with ext3,
Hans
Theodore Ts'o wrote:
>However, logically speaking, if a filesystem is designed such that in
>certain cases, the fsck program has to brute-force search every single
>disk block looking for data structures that _look_ like they might be
>part of the filesystem data, well, that's always going to be more
>error prone than one where the filesystem metadata is in
>easily-predicted locations. It sounds like you've added some more
>checks in reiser4, and that's definitely a good thing. Time will tell
>whether they are sufficient or not.
>
>Regards,
>
> - Ted
>
>
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
