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. _______________________________________________ Ext3-users mailing list Ext3-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/ext3-users
