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