[ On Friday, January 26, 2001 at 16:06:10 (-0500), der Mouse wrote: ]
> Subject: Re: SCSI device tuning tool
>
> 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).

True enough -- I mostly replied just so that I might introduce any
missing information that I might have left out so that those who might
decide on the fate of NetBSD were well informed, at least about my
thoughts on the matter.  :-)

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

Ah, of course.  I had forgotten that '-o sync' was available on a
per-mount basis now (and unfortunately I see the documention doesn't say
which is the default state of this flag!).

Turning on MNT_SYNCHRONOUS is not 100% necessary to maintain the
integrity of the data provided the system is stable, has ECC RAM,
running on a good UPS, etc..  If the system crahses unexpectedly nothing
(filesystem-wise) will be damaged per se -- all that will happen is a
that the most recently written data (from the application's perspective)
might be lost.  It's really no different than if the machine had crashed
a few seconds earlier -- an unexpected crash is, well, unexpected, so
logically it makes no difference if it appears from the data stream to
have happened a few seconds earlier than it really did.

On the other hand turning on MNT_ASYNC raises the risks unnecessarily
because if an even stable but busy system crashes unexpecetedly with
metadata out-of-sync then more than just the unwritten data might be
damaged, i.e. the on disk filesystem structure's state would unknown
following a crash and all hell could break loose if you ran 'fsck -y'
against it.

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

The driver should always automatically enable AWRE and ARRE upon mount
of any partition on the device unless explicitly told not to (perhaps
even on a per-mount operation basis).  A mount command-line parameter
could be used to disable this feature, and/or it could be done with a
sysctl or compile-time driver flag on a per-device basis.

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

Well, OK, but....  I think you're looking too closely at the forest and
you're only seeing trees!  :-)

There are many more cases where it's the filesystem structure and the
contents of the files which must be left untouched, not their particular
layout on the physical media -- a successfull reallocation on read due
to ARRE will not change anything for all intents and purposes since what
it does is totally invisible (well, except for some possibly noticable
timing differences) to the normal ways of accessing the data on the
disk.  Of course if the reallocation fails then it doesn't matter
whether it was attempted or not -- the data's gone either way.

If you really want the disk to be unwritable at the physical level then
toggle the read-only/write-disable jumper on the hardware -- don't trust
the driver not to touch anything!  That's what those jumpers are there
for after all!  (I don't know if these jumpers commonly prevent
modification of mode page values or not.)

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

Those other things are related to performance (unless I've missed
something critical).  ARRE and AWRE are related to data integrity.  If
the disk works safely but slowly that's not necessarily a bad thing, but
if it works unsafely at any speed, then that's bad.  Obviously if the
drive knows it's going to be slow going due to some mismatch with the
mode page parameters then it might make some noise about the issue just
so that the user doesn't blame the wrong thing, but if the driver allows
the data it reads from (or writes to) the disk to be lost then the
average user's *not* going to blame themselves for forgetting to check
the if the recovery bits were enabled.

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