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>