Re: [Ext2-devel] Re: [PATCH] ext3: Extends blocksize up to pagesize

[Andreas Dilger <adilger@clusterfs.com>]

On Jan 22, 2006  13:28 -0500, Theodore Ts'o wrote:
> On Wed, Jan 18, 2006 at 10:48:06AM -0500, John Stoffel wrote:
> > In that size range, you really need a filesystem which doesn't need an
> > FSCK at all.  Not sure what the real answer is though...
> 
> Ext3 doesn't require a fsck under normal circumstances.  The only
> reason why it still requires a periodic fsck after some number of
> mounts is sheer paranoia about the reliability of PC class hardware.
> All filesystems need some kind of filesystem consistency checker to
> deal with filesystem corruptions caused by OS bugs or hardware
> corruption bugs.  The only question is whether or not the filesystem
> assumes at a fundamental level whether or not the hardware can be
> trusted to be reliable or not.  (People have claimed that XFS is much
> less robust in the face of hardware errors when compared to ext[23]; I
> haven't seen a definitive study on the issue, although that tends to
> correspond with my experience.  Other people would say it doesn't
> matter because that's why you pay $$$$$ for am EMC Symmetrix box or an
> IBM shark/DS6000/DS8000, or some other Really Expensive Storage
> Hardware.)

I think the work done by the U. Wisconsin group for IRON ext3 is the
way to go (namely checksumming of filesystem metadata, and possibly
some level of redundancy).  This gives us concrete checks on what metadata
is valid and the filesystem can avoid any (or further) corruption when
the hardware goes bad.  The existing ext3 code already has these checks,
but as filesystems get larger the validity of a block number of an inode
is harder to check because any value may be correct.  Given that CPU
speed is growing orders of magnitude faster than disk IO the overhead of
checksumming is a reasonable thing to do these days (optionally, of course).

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/