[ On Sunday, January 21, 2001 at 00:50:51 (-0500), der Mouse wrote: ]
> Subject: Re: SCSI device tuning tool
>
> >>> I still think the NetBSD SCSI driver should always force AWRE and
> >>> ARRE to be on all of the time (except maybe for AWRE if the device
> >>> is only open read-only),
> >> I don't.  If for any reason I have a disk set to no auto
> >> reallocation, I do not want the driver to take it upon itself to
> >> assume that's a mistake on my part.
> > Sorry, but if the driver's not explicitly going to handle the errors
> > in the best possible way
> 
> The trouble is, the driver is in no position to determine what "the
> best possible way" is, since it depends on factors the driver cannot
> discover, such as human intentions.

It's perfectly simple:  You always need ARRE enabled if there's a
filesystem mounted.  You need AWRE enabled only if you're going to write
filesystem data to the device.  Anything else is less than "best".

> > then it should endeavour to make sure that they are handled at the
> > lower level!
> 
> Then where's the panic if you try to boot on a machine with non-ECC
> RAM?

I try never to use any machines with un-protected main memory (and
thankfully most have protected cache) unless that system isn't doing
anything other than handling data that doesn't need high integrity (like
a router -- it's only really processing data that's possibly already
corrupted by transmission errors).

> What's wrong with doing a read-only surface scan on a mounted disk?

nothing -- if you know what you're doing and you understand the possible
consequences.

> >> Printing a warning, fine.  Changing it, not fine.
> > I may be mistaken but I was under the distinct impression that all
> > SCSI disks returned a warning when they "fixed" a block anyway,
> 
> Irrelevant.  The warning I'm talking about is more like
> 
> sd1 at scsibus0 targ 2 lun 0
> sd1: 2050MB, ....
> sd1: warning, automatic block reallocation is disabled!

Yeah, that's what I was afraid of.  That would be a good warning to
have, but only if the driver cannot handle bad block reassignment
itself, *and* cannot enable ARRE and AWRE.

> > If you mean to print a warning when the ARRE and AWRE bits are not
> > set as one would logically have them set for a production system,
> > then yes I think this should be a minimum requirement, but it's not
> > safe enough.
> 
> Safe how?  I don't consider it safe for the driver to silently change
> permanent state on my disks, permanent state that it has no reason to
> think I want changed.  Just because *you* want it that way on *your*
> disks is no excuse for the driver assuming *I* want it that way on *my*
> disks.

You're reading far too much into what you think you have control over in
something like a modern SCSI disk.  You have no control, and on some
modern disks (eg. IBM drives with S.M.A.R.T.) the drive is incredibly
more intelligent than any driver could ever be.  For most NetBSD users
today the likely state of the ARRE and AWRE bits on their disks is
purely random, and certainly unknown.

In any case this is purely an issue between the drive and the driver --
what you as the hardware hacker want is irrelevant if you've told the
driver to store or retrieve precious data to/from the drive.  It must
default to doing what's best for the data, not for you the hardware
hacker.

> I could probably live with that, but it's still backwards: safe, to me,
> means don't mess with stuff you haven't been told to mess with.  In
> particular, it means don't mess with the automatic reallocation
> settings (or any other permanent state, for that matter) without
> explicit configuration to that effect.

Safe means "safe for the user's data".   If the drive state is incorrect
and will risk the user's data, then it is not safe and must be corrected
automatically.  Only the driver is in a position to know whether or not
it can deal with the errors, and if not it must endeavour to make sure
that the underlying hardware operates in the safest way it knows how to.

> Then why does fsck pay attention to clean bits?

That's obviously just an optimisation.  Most people are willing to risk
that those bits won't change on the disk between shutdown and reboot and
they're also willing to take the risk that the OS wrote those bits in
the correct order and that it itself wasn't fragged when it did so.

Certainly I don't allow fsck to pay attention to the clean bits if I
think my OS was in any kind of unstable state when I shut it down.   I
always manually boot and manually force fsck to run in that case.

>  Why is NetBSD willing
> to run in non-ECC RAM?

It shouldn't by default, IMNSHO.  Though like I say it's not such a big
concern in certain types of applications, so this is a decision that
should be consciously made by the user.

>  Why aren't all filesystems mounted with
> MNT_SYNCHRONOUS unless told otherwise?

You mean some writable filesystems are not?  I was under the impression
from the documentation that you had to use '-o async' to turn that flag
off, and the docs say async "is a _dangerous_ flag" (emphasis theirs).

> There are lots of cases where NetBSD doesn't do maximal integrity
> paranoia.

Ah, key word:  "paranoia".  Paranoia has no place in a real risk
assesment.

In the case of ARRE and AWRE there's no paranoia involved.  Disk media
errors are inevitable -- there's no risk that they will never happen
(note the intentional double negative! :-).  Ignoring this certain
threat is unfounded optimism.  Having the OS and hardware deal with it
as best they can is not paranoia -- it's just good common sense (well
maybe not so common given that it isn't yet done and that most people
have problems understanding risk, including even me unless I think about
it real hard and write everything down).

> > Now that I've thought about this more I believe I've only seen these
> > bits disabled by default on modern drives that [...].  However in
> > true NetBSD tradition there should be clean and safe ways of using
> > such drives for other purposes!  :-)
> 
> I don't consider it "safe" if putting such a disk on a NetBSD system
> will magically and silently render it unusable - or at least severely
> nonperformant - if it's later put back where it came from.

Huh?  Since when would that ever happen?  My bet is any AV equipment
will ram those bits back to the way it wants them.  I.e. without fixing
the NetBSD drivers you'd probably render a disk unsafe by temporarily
using it in an AV system!

Not only that but unless the disk is nearing the end of its lifetime
then the only problem the AV system might have with ARRE and AWRE
enabled is that it too might "suffer" from higher data integrity than it
really needs, and then instead of instantly warning the user of a "bad"
disk when one sector fails hard it'll begin to suffer performance
"problems" as the drive has to seek to find the re-mapped sector.

In any case automatically enabling ARRE and AWRE upon mount is still the
"safe" thing to do in NetBSD because no matter what you're going to do
with the disk after you take it out of your NetBSD system, while it is
installed and being used by NetBSD the driver must make sure that it
does what it can to ensure the integrity of the data it stores and
retrieves from that disk.

What you do with a disk after you take it out of NetBSD's hands is your
problem, not NetBSD's.  If indeed your AV system fails to work because
you've temporarily used one of its disks in a NetBSD system then I think
the AV vendor will simply note that you've violated the warranty and
make you buy a new disk instead of telling you that if you only
re-connected the disk to the NetBSD box and cleared the ARRE and AWRE
bits without mouting a filesystem then you could use it in the AV system
again.

Finally note that many of these high-end AV drives are available by the
bucket load in some surplus shops because once they exhibit one bad
sector they're useless for AV equipment, while they might only be 25%
into their useful lifetime from the point of view of a NetBSD user.  If
NetBSD can safely breathe an extra lifetime into such otherwise junk
drives then don't you think that's a good thing?

Of course there are other interesting flags and configuration values
stored in the mode pages of the average SCSI drive that could often be
tuned to gain better performance, etc.  However I won't even try to
argue that the driver should touch any of these without direct human
intervention.....  :-)

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>