Glen, As far as I know, the setting of the IO$M_DATACHECK flag on the Logical Reads and Writes is determined by the settings of the bits in the ACP_DATACHECK SYSGEN parameter. If you are seeing the IO$M_DATACHECK flag being passed down on systems which have the bits on ACP_DATACHECK set to zero, then I would be very worried. I just checked the XQP listings, and at no point is the IO$M_DATACHECK parameter set unconditionally. To my mind, this should be sufficient control over datacheck, though you may want greater detail in the documentation of the SYSGEN parameter, to explain just what Datacheck means. regards /Duncan ---------- From: everhart@row.enet[SMTP:everhart@row.enet] Sent: Thursday, September 26, 1996 4:19 PM To: movies::mclaren Subject: What can we do if anything? Duncan - Seems to me we ought to think about this, maybe do something quickly. Modification to dkdriver to allow a customer to turn datacheck off and on is simple. (I don't offhand know where the mount/data_check flags are stored...it'd help...but I had to fix a dkdriver up to get around the Burns disk problem and have a working disable now. A sys$etc: utility to do it is straightforward. If you folks approve of having such a thing, a program interface might be added to allow the change & report status by "invisible" means (eg, use a function modifier on some phys i/o fcn) to support this more easily. If you don't approve, the ability will have to be latent and you'd need to bash the DK UCB in the "right" place to accomplish this...and with the "right" bit set...not a commonly easy thing. My personal belief is that datacheck oughta be off for SCSI. For other storage I can't say. Part of the question is whether the XQP should be using it in the first place, or whether it should be headed off in the driver instead via some customer option. And what should the default be? Glenn Everhart (You may want to copy Len Szubowicz on replies) From: MOVIES::STAR::JPALMER "26-Sep-1996 0837 -0400" 26-SEP-1996 08:46:00.16 To: MOVIES::ROW::EVERHART CC: MOVIES::HOWELL_MA,MOVIES::GREEN,JPALMER Subj: RE: Data Check 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 % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from halt ([16.196.144.44]) by vbormc.vbo.dec.com (8.7.3/8.7) with SMTP id QAA08471 for ; Thu, 26 Sep 1996 16:52:16 +0200 % Received: by gt750.vmse.edo.dec.com with Microsoft Mail id <01BBABC2.DA1401D0@gt750.vmse.edo.dec.com>; Thu, 26 Sep 1996 15:53:25 +010 % Message-ID: <01BBABC2.DA1401D0@gt750.vmse.edo.dec.com> % From: Duncan McLaren % To: "'everhart@row.enet'" % Cc: "'Szubowicz@star.zko'" % Subject: RE: What can we do if anything? % Date: Thu, 26 Sep 1996 16:53:01 +0100 % Encoding: 123 TEXT