>>>>> 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.
>>> [...] 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".

I see little point in continuing this discussion much longer, since it
is based on a fundamental difference of opinion.

You appear to be writing from a perspective of "safety of data bits is
paramount"; I am writing from a perspective of "do what I tell you and
nothing else, dammit".  Naturally, your idea of "best" in this context
differs from mine, and since neither of us likely to convert the other
on this point, there's nothing more to discuss (except, possibly, which
of us gets to be happy with NetBSD's default, and that's more a matter
for those controlling NetBSD to decide).

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

There is no way, in the current model, to tell the driver the
difference between precious data and not-so-precious data.  It is not
for the driver to arrogate to itself the right to decide what level of
reliability I want used for my data!  (In my opinion, of course, which
I fully expect you to disagree with.)

>> Why aren't all filesystems mounted with MNT_SYNCHRONOUS unless told
>> otherwise?
> You mean some writable filesystems are not?

Certainly.  No filesystem is unless it's explicitly mounted that way.

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

-o async doesn't turn off MNT_SYNCHRONOUS; it turns on MNT_ASYNC.
MNT_SYNCHRONOUS and MNT_ASYNC are separate bits, both off by default;
while it makes no sense to turn both on, it makes perfect sense to turn
both off, and indeed that's the default state: some writes are then
done synchronously, some asynchronously, at the judgement of the
filesystem code in question.

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

I don't see what other word could reasonbly fit your insistence that
the driver must do everything in its power to safeguard that "precious
data", even in the face of a disk configured with automatic
reallocation disabled.  The driver has no way to tell whether it's
accidental or deliberate, after all.

I most particularly do not want ARRE forced on for a readonly disk; if
I access a disk read-only, I do not want any permanent state changes.
Ever.  For any reason.  For as long as it's open only for read.
(Absent, of course, explicit human action to configure it otherwise.)
Indeed, now that you've brought it up, I'm considering tweaking the
driver to force ARRE *off* when the disk is open read-only.

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

Yes.  But I don't consider it unreasonable to require explicit user
action to either remap the bad sector(s) or turn on ARRE and AWRE -
indeed, as I've explained, I consider it unreasonable to do so without
explicit user action.

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

Why not?  You've just argued at some length that it's the driver's
responsibility to configure the disk for as much reliability as it can;
why should that include ARRE/AWRE but not those other bits?  What's the
difference?  I really don't see it.

					der Mouse

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