Date: 30 Mar 2001 15:36:18 -0500 From: Randell Jesup <rjesup@wgate.com> To: Bakul Shah <bakul@bitblocks.com> Cc: Kirk McKusick <mckusick@mckusick.com>, arch@FreeBSD.ORG Subject: Re: Background Fsck Message-ID: <ybu8zlngfjx.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net> In-Reply-To: Bakul Shah's message of "Fri, 30 Mar 2001 09:53:06 -0800" References: <200103301753.MAA03709@valiant.cnchost.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Bakul Shah <bakul@bitblocks.com> writes: >But like Terry I worry about disks write errors or blocks >going bad. And not knowing how well the bg fsck (or for that >matter soft-updates) copes with that gives me an uneasy >feeling. Perhaps bg fsck should not do anything if it >discovers structural inconsistency? This worries me too. However, "not doing anything" can be a problem if the system isn't being actively monitored. >I know I don't have to run it if I feel this way but the >point is to understand the behavior. Yes. >> Many improvements have been made to fsck over the years. Through >> there are undoubtedly more that could be made, there are no big >> easy improvements left. > >I was less than clear; what I was asking is if anyone has >looked at whether the fsck *algorithm* is optimal. I >wondered about its complexity -- is it O(n^2) or O(n log n) >or something else and whether it is the best possible >algorithm. Also think about the memory usage requirements. FS checkers on big drives can be memory hogs; I don't know about fsck. I'm guessing that it's O(n) so long as you don't run over memory requirements, but that could easily happen. -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ybu8zlngfjx.fsf>