Date: Mon, 17 Mar 2003 22:39:02 +0100 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Bakul Shah <bakul@bitblocks.com> Cc: Julian Elischer <julian@elischer.org>, FreeBSD current users <current@FreeBSD.ORG>, fs@FreeBSD.ORG Subject: Re: Anyone working on fsck? Message-ID: <54291.1047937142@critter.freebsd.dk> In-Reply-To: Your message of "Mon, 17 Mar 2003 13:26:56 PST." <200303172126.QAA23205@thunderer.cnchost.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <200303172126.QAA23205@thunderer.cnchost.com>, Bakul Shah writes: >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. Now, before we go off and design YABFS, can we just get real for a second ? I have been tending UNIX computers of all sorts for many years and there is one bit of wisdom that has yet to fail me: Every now and then, boot in single-user and run full fsck on all filesystems. If this had failed to be productive, I would have given up the habit years ago, but it is still a good idea it seems. Personally, I think background-fsck is close to the ideal situation since I can skip the "boot in single-user" part of the above profylactic. If you start to implement any sort of journaling (that is what you talked about in your email), you might as well just stop right at the "clean" bit, and avoid the complexity. Optimizing fsck is a valid project, I just wish it would be somebody who would also finish the last 30% who would do it. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. 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?54291.1047937142>