Thanks for your thoughts. . Some good points..
On Mon, 17 Mar 2003, Bakul Shah wrote: > UFS is the real problem here, not fsck. Its tradeoffs for > improving normal access latencies may have been right in the > past but not for modern big disks. The seek time & RPM have > not improved very much in the past 20 years while disk > capacity has increased by a factor of about 20,000 (and GB/$ > even more). IMHO there is not much you can do at the fsck > level -- you stil have to visit all the cyl groups and what > not. Even a factor of 10 improvement in fsck means 36 > minutes which is far too long. Keeping track of 67M to 132M > blocks and (assuming avg file size of 8k to 16k) something > like 60M to 80M files takes quite a bit of time when you are > also seeking all over the disk. Puting indirect blocks nearer the cylinder group metadata for the group that contains the inode would be nice :-) > > A few ideas: > > When you have about 67M (2^26) files, ideally you want to > *avoid* checking as many as you can. Given access times, you > are only going to be able to do a few hundred disk accesses > at most in a minute. So you are going to have only a few > files/dirs that may be inconsistent in case of a crash. Why > not keep track of that somehow? In the case of HW failure on a raid you REALLY need to checke everything. You don't trust anything.. > > If you need about 1GB of space to store the state of a TB > file system that needs to be checked, may be it _should_ be > *stored* in a contiguous area on the FS itself. 1GB is about > 0.1% of space. It is no trouble for us to set asside a separate filesystem, or partition for this.. > > Typically only a few cyl grps may be inconsistent in case of > a crash. May be some info about which cyl groups need to be > checked can be stored so that brute force checking of all > grps can be avoided. > > Typically a file will be stored in one or a small number of > cyl groups. If that info. is stored somewhere it can speed > things up. > > Extant based allocation will reduce the number of indirect > blocks. But may be this is not such a big issue if most of > your files fit in a few blocks. > > Anyway, support for all of these have to be done in the > filesystem first before fsck can benefit. > > If instead you spend time "optimizing" just fsck, you will > likely make it far more complex (and potentially harder to > get right). > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message