From owner-freebsd-arch  Wed Jan 17 23:39:36 2001
Delivered-To: freebsd-arch@freebsd.org
Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134])
	by hub.freebsd.org (Postfix) with ESMTP
	id A78A537B402; Wed, 17 Jan 2001 23:39:16 -0800 (PST)
Received: (from daemon@localhost)
	by smtp04.primenet.com (8.9.3/8.9.3) id AAA03583;
	Thu, 18 Jan 2001 00:34:19 -0700 (MST)
Received: from usr08.primenet.com(206.165.6.208)
 via SMTP by smtp04.primenet.com, id smtpdAAAgDai_g; Thu Jan 18 00:34:16 2001
Received: (from tlambert@localhost)
	by usr08.primenet.com (8.8.5/8.8.5) id AAA00872;
	Thu, 18 Jan 2001 00:39:11 -0700 (MST)
From: Terry Lambert <tlambert@primenet.com>
Message-Id: <200101180739.AAA00872@usr08.primenet.com>
Subject: Re: dynamic vs static sysctls?
To: bright@wintelcom.net (Alfred Perlstein)
Date: Thu, 18 Jan 2001 07:39:11 +0000 (GMT)
Cc: dot@dotat.at (Tony Finch), msmith@FreeBSD.ORG (Mike Smith),
	mckusick@mckusick.com (Kirk McKusick), arch@FreeBSD.ORG
In-Reply-To: <20010117230622.K7240@fw.wintelcom.net> from "Alfred Perlstein" at Jan 17, 2001 11:06:22 PM
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-arch@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> > >> 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