On Tue, Mar 11, 2008 at 9:37 PM, Bruce Hayden <[EMAIL PROTECTED]> wrote:
> Are they reverting back to diag disabled after a reboot? I've had > this kind of problem making the diag driver "stick" for vdisks. The > Yast installer allows you to tell it that certain disks are "diag > enabled", but then it seems to forget that when you first boot the > system. So - I enable it with this sequence. In this example, disk IMHO that's because 'mkinitrd' was not designed to be used by adults. It tries to guess at what you may need next time by looking at what you use now. You could also tell it explicitly you want the dasd_diag_mod included in the ramdisk (through one of the configuration files, or by additional parameters). Since we're not speaking on Linux-390, I dare to say this.... ;-) A lot of this weird stuff is due to ignorance and paranoidism among the Linux developers. The connection between DIAG250 and CMS RESERVE is entirely artificial and self-imposed restriction from the Linux device driver. After all, CMS works fine with DIAG I/O on normal disks. The only thing DIAG I/O needs is all (most) tracks formatted with blocks of the same size. That's what CMS does, and that's also what Linux requires. Whether you format an FBA device (a virtual one even) with 1K or 4K blocks is a matter of taste only, it does not affect the virtual metal oxide on the platters. (that's why it is so quick). When you do SSCH, you will have to do records of 512 byte because that is what the disk is like. Doing always groups of 8 consecutive blocks in a channel program to fill a 4K page is something for the operating system (but it does cause both Linux and CP some pain, so I see a market for 4K FBA devices). But when you do DIAG250, all that CP gets is a list of blocks. You can pick your favorite standard block size (4K makes much sense) and CP can do the math to compute which 512-byte blocks correspond to your 4K blocks. For DIAG250 real ECKD it's not even much harder. CP knows how many of the standard blocks fit on a track, so CP can divide your 4K block number by 12 to compute track and record. Even when track 0 would be done with funny blocks, CP will not complain as long as you don't try to get block 0-11 from the disk. I have asked Endicott before to just document that this works, and provide a new DIAG250 subcode to retrieve the label and some more from track 0. With that in place, the choice between DIAG or SSCH would be entirely transparent to the next layer in Linux, and could be based just on the fact that you run on z/VM (since I still believe DIAG I/O is much wiser than SSCH). Rob -- Rob van der Heij Velocity Software, Inc http://velocitysoftware.com/
