the beasties each time you change them.
The other key is to be sure to dasdfmt them as cdl - compatible disk layout. That is the default, so you would have to intentionally
change it to do otherwise.
Now, a dump z/VM question - with DDR, I usually link the minidisks I am copy to copy and do a COPY ALL.
I saw in a previous message that someone was doing a DUMP ALL and RESTORE ALL. My limited understanding
is that DUMP and RESTORE only seem to work to tape - is that correct?
Or is there an easier way to copy volumes around lurking in there somewhere???
I *never* have trouble with the COPY ALL bit.
-Paul
--- Begin Message ---
Kim,
Good analogy. But these are not new DASD, they have been "well-used". The were originally formatted with ICKDSF before ever being used by VM. Now we're just carving up some set of previously used cylinders for use by Linux. Since the cylinders had previous lives (perhaps as a CMS minidisk, perhaps as part of multiple CMS minidisks, perhaps even as part of a Linux minidisk) they had been "hardware formatted". If previously used as CMS minidisks they certainly had 4k blocks written all over them. If previously used as a Linux mdisk, then before that they had been used as a CMS mdisk, again having been well-used before the first time Linux ever saw them.
I would expect that as long as dasdfmt completed successfully, then it should have written everything Linux would need to use the device - not just formatting part of the disk. I'm still leaning towards Linux expecting to see some sort of label or VTOC, that for some reason dasdfmt doesn't (always?) write. Perhaps in the cases where Linux could use the new MDISK after dasdfmt, it was because in a previous life the first cylinder of the MDISK had been the start of a CMS or OS MDISK. Maybe we only need to format cylinder zero of each new Linux guest MDISK to get a label or VTOC written. Or, maybe we just need to add another parameter to the dasdfmt command to get such written so we can skip the CMS format?
Mike Walter
Hewitt Associates
The opinions expressed herein are mine alone, not my employer's.
"Kim Goldenberg" <[EMAIL PROTECTED]>
Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>05/23/2006 02:11 PM
"The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>
IBMVM@LISTSERV.UARK.EDU Re: Moving a guest to new DASD
Mike Walter wrote:
>
> An IBMer from Omaha told us that one should always format with CMS or
> ICKDSF before giving an MDISK to a Linux guest before the guest
> formats the MDISK with "dasdfmt". No reason for the CMS or ICKDSF
> format was given.
>
> Formatting an MDISK twice really, really (pun intended) rubs me the
> wrong way.
Except you are not really formatting it twice. You are formatting the
hardware disk in CMS format the first time, and then "formatting" the
area withing that space for Linux's use (dasdfmt). just laying down data
within the MDISK. It' kinda like the pre-ata hard drives that had to be
hardware formatted (with a servo track or some other) the first time,
before you could DOS format them. Think of the ICKDSF format as a
hardware format and the dasdfmt as the software format, even though both
are software generated. The CMS format is just arranging the ECKD dasd
in 4k blocks with the appropriate pseudo-IRGs betweeen them. Linux is
then putting down it's formatting on the disk so that ext2/3 can find
the eyecatchers it's looking fo on the disk. Remember, the file system
doesn't care what is on the disk, but is expecting information that
dasdfmt has left behind, perhaps in control blocks in the first block or
two of the "partition". That partition has to look the same on my laptop
as on a SCSI disk, as on a USB keyfob drive, as on a 3390...
>
> But we have experienced inconsistent problems with MDISKs given to
> Linux guests after formatting with only "dasdfmt" (i.e. not with
> ICKDSF or CMS FORMAT). Sometimes the MDISK worked with only dasdfmt,
> other times Linux would not recognize it and we had to format it with
> CMS, then dasdfmt. When at a Linux workshop in Poughkeepsie, the IBM
> instructor related that Linux mdisks should always be formatted by CMS
> or ICKDSF before giving them to the Linux guest to beformatted with
> "dasdfmt" - having experienced random failures himself.
> I suspect that the problem is related to the MDISK needing a volser or
> dummy VTOC, but have never had time to research it. My guess is that
> skipping the CMS format works when the newly defined MDISK happens to
> align with a previously used MDISK beginning at that same cylinder
> extent.
>
> Does anyone have a verifiable explanation for the requirement to
> format the MDISK before giving it to Linux for a dasdfmt? It may
> explain Loren's problem, too.
See above. I hope I've cleared it up and not confused it for you.
>
> Mike Walter
> Hewitt Associates
> The opinions expressed herein are mine alone, not my employer's.
Kim Goldenberg
State of NJ - OIT
The opinions expressed herein are mine alone, not my employer's.
The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited.
--- End Message ---
