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

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

>> In particular, that would make it impossible to do diagnostic
>> surface scans with the likes of sdd (or at least it would be much
>> less useful to try to).
> As I've already hinted I think the driver should only turn these bits
> on when a filesystem is mounted (I should have used that more correct
> word rather than "open").

I don't think the driver is in a position to tell open-for-mount from
open-for-other-reason.  (Admittedly, this is probably fixable without
too much pain.)

> Given that logic there won't be anything to prevent you from doing a
> "passive" analysis.  Note that if you're doing surface scans with a
> filesystem mounted then something's wrong!

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

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

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

> Alternately there could be a driver flag set at compile time or with
> gdb (and perhaps at run-time through a sysctl) that could disable
> automatic enabling of the ARRE and AWRE bits -- this way everyone
> would have the default "safe" conditions and yet hardware hackers
> could disable it as necessary.

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.

> Just as with any other "security" issue, I think integrity must take
> a first-row "always on by default" position and those who don't like
> it that way can be free to take the risk of putting it at the back of
> the bus instead.

Then why does fsck pay attention to clean bits?  Why is NetBSD willing
to run in non-ECC RAM?  Why aren't all filesystems mounted with
MNT_SYNCHRONOUS unless told otherwise?

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

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

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B