Date: Mon, 17 Mar 2003 13:51:59 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: Bakul Shah <bakul@bitblocks.com> Cc: FreeBSD current users <current@FreeBSD.ORG>, fs@FreeBSD.ORG Subject: Re: Anyone working on fsck? Message-ID: <Pine.BSF.4.21.0303171347550.70394-100000@InterJet.elischer.org> In-Reply-To: <200303172126.QAA23205@thunderer.cnchost.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0303171347550.70394-100000>