maintain 6TB filesystem + fsck

Andreas Dilger adilger at clusterfs.com
Fri Dec 1 12:44:34 UTC 2006


On Nov 30, 2006  21:55 -0500, Joseph Cheng wrote:
> http://listman.redhat.com/archives/ext3-users/2006-October/msg00005.html
> 'The major problem at this point is e2fsck time, which is about 1h/TB
> for fast disks, at minimum (i.e. no major corruption found).'
> .........is that ext3 or ext4?

I don't think it really matters.

> i don't know how long fsck will take w/ 6TB ext3 filesystem.

You have such a filesystem, test it...

> i first choose to disable auto fsck with 'tune2fs
> -i0 -c0 /dev/sda1' but seems dangerous if filesystem become corrupt
> without my knowledge! what is good balance betwen using auto fsck
> after number of mounts or time pass and keeping fsck time short for
> large arrays? info......

You can optionally run e2fsck -fn on a relatively quiet (though mounted)
filesystem, and if it checks (relatively) clean then you could reset the
fsck time in the superblock via tune2fs.

> filesystem expected to contain 10 mb files to maybe even 50 mb + 100mb

One of the major slowdowns for e2fsck is the number of inodes, so if you
expect to have very large files you should create the filesystem with
this in mind (i.e. "mke2fs -t largefile" or "mke2fs -t largefile4").
Expect e2fsck RAM usage to be about .75 * num_inodes + .25 * num_blocks,
so in the neighbourhood of 500MB for your filesystem, so reducing inode
count would also help this a fair amount.

We are working on a patch to e2fsck and the kernel to allow e2fsck to
skip unused inodes/bitmaps in each group so that e2fsck time is improved.
It isn't quite ready for prime time, but has previously been discussed
in linux-ext4 in relation to the UNINIT flags in recent e2fsprogs.  It
would at least reduce e2fsck time to O(used_inodes) from O(total_inodes)
and also potentially avoid a lot of seeky IO.

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




More information about the Ext3-users mailing list