Hi Glenn,

Yes, this sounds like a good idea. Since we aren't taking anything away from
existing sites, I'd vote for disabling the real datacheck by default, perhaps
making it occur only when selected by MOUNT/DATA_CHECK is specified ? Maybe the
XQP could even be changed to verify the setting of datacheck before setting
IO$M_DATACHECK on its QIOs... Duncan (MOVIES::) Mclaren is the XQP leader. FYI
Spiralog V1 doesn't set IO$M_DATACHECK.

Julian

From:	MOVIES::ROW::EVERHART     25-SEP-1996 17:19:43.99
To:	MOVIES::HOWELL_MA,MOVIES::PALMER
CC:	
Subj:	Data Check

Guys...

I've noticed that many (all?) filesystem operations use the io$m_datacheck
modifier writing to disk.

I don't know if it does anything on other architectures, but on SCSI
in VMS 7.0 and before, alpha and I think vax, it did nothing. This was
because it didn't tell the drive to read off disk, and so got data
off the drive cache, a rather useless operation.

Now dkdriver uses "force unit access" to force reading the disk. This
works right, but every datacheck now gets at least one extra drive
rotation to read the data. SLOW. This means that the VMS filesystem is
getting turned into a real slow one by this option.

Since we haven't had the option working in the past, I wonder if you'd
be amenable to some interface that turns datacheck off, at least as a
user option? I had to code one for the Burns disk (the drive firmware
has bugs, doesn't handle cache right with mixed FUA and non-FUA reads)
but it's for that only at the moment.

What would you say to allowing customers to select this? The performance
delta may be large, and the "added protection" hasn't really been there
till now anyway. It could hit our I/O benchmarks rather hard as it stands,
and for no good reason I can think of. (To be philosophical about it, 
what right do we have to consider our data more valuable than the user's,
and why do we datacheck when the customer has mount qualifiers to do
datacheck if he wants them? Why should this be there at all for modern
architectures? (I can understand it for massbus or unibus disks that had
higher error rates, but geez...)

I'm worried also about other disks that may have firmware problems like
the ones I saw with the Burns disk; there's no way to tell other than
experiment and getting lucky in hitting it while a SCSI analyzer is
running.

)

Till now, we've been able to rely on the disk telling us all went ok
and data is now on disk. Why not let the user decide how paranoid he
feels like being about this, and at the same time therefore justify
us using benchmarks that don't hit this penalty. Lord knows there are
enough other slowdowns in file processing that we need another like
a hole in the head. And the current state of dkdriver WILL show a
slowdown, basically for the first time, in this area.

Lenny S. asked me to get y'all involved, so can you help and get this
to the right folks to discuss it if you're not?
Thanks
Glenn Everhart