Date: Thu, 18 Jan 2001 07:39:11 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: bright@wintelcom.net (Alfred Perlstein) Cc: dot@dotat.at (Tony Finch), msmith@FreeBSD.ORG (Mike Smith), mckusick@mckusick.com (Kirk McKusick), arch@FreeBSD.ORG Subject: Re: dynamic vs static sysctls? Message-ID: <200101180739.AAA00872@usr08.primenet.com> In-Reply-To: <20010117230622.K7240@fw.wintelcom.net> from "Alfred Perlstein" at Jan 17, 2001 11:06:22 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> > >> In my work on a background version of fsck, I have used sysctl to > > >> allow me to pass information into the kernel that I want to have > > >> updated in the filesystem. > > > > > >I'm not convinced that sysctl is the "right" way to go about doing this, > > >really. But I can't think of a better one. 8) > > > > Why not an ioctl on the disk device? You could arrange to pass in an > > array of free blocks to reduce the number of syscalls. > > It's not a disk action, it's an FS action, an fsctl call might be handy, > or a completely static sysctl, but not a disk device ioctl. FWIW, this really depends on whose job you think it is to keep track of bad blocks and virtually "fix" them. SVR4.2 and above, for example, do the bad-block fixing and retries at or below the device driver level. Using this approach, bad blocks would never be known to the FS under any circumstances. There was a nice bug in the SVR4.2 Veritas implementation that used to make /usr disappear back when UnixWare was at "SVR4.2-prerelease", where soft errors were reported outside the device driver to the FS code, instead of "soft fixed" before the FS code ever saw them. Something to gloat about when the Linux Veritas port is released, until they fix their drivers to only report up unrecoverable hard errors, too, I guess, and a barrier to entry for a BSD Veritas port, until BSD does the same, or Veritas becomes irrelevent (may be quite a while). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?200101180739.AAA00872>