It looks like our updates are crossing in the mail.
Sorry about that. I'll try to answer your additional questions.
The following is an oversimplification, but it gets the point across.
A CMS minidisk on a CKD device has the following logical format:
----------------- /dev/dasda -----------------------
IPL record 1
IPL record 2
CMS label record
Additional CMS filesystem overhead
----------------- /dev/dasda1
Begin Implicit partition 1 (the only partition) and Linux file system
.
.
.
.
.
end of Linux file system
beginning of RECOMP area
.
.
end of RECOMP area, end of partition 1, end of minidisk
The primary purpose of the RECOMP area is to store an IPL-able program,
which is a continuation of the first two IPL records on cylinder 0,
track 0, records 1 and 2. This is what the CMS operating system uses
it for. For example, when running CMS, the command
CP QUERY VIRTUAL 0190
returns 107 cylinders as the size of the minidisk. But
QUERY DISK S
returns 100 cylinders as the size of the minidisk. The difference of
7 cylinders is the size of the RECOMP area at the end of the minidisk.
That is where the CMS nucleus is stored, and when I issue the command
CP IPL 0190
The CMS nucleus gets booted from the RECOMP area.
Compare this to, say, a cdl minidisk
---------------- /dev/dasda --------------------------
IPL record 1
IPL record 2
Disk label
IPL record 3
IPL record 4
.
.
.
end of IPL records
VTOC (i.e. partition table)
-------------- /dev/dasda1 ----------------------------
Begin partition 1
End partition 1
-------------- /dev/dasda2 ----------------------------
Begin partition 2
End partition 2
--------------- /dev/dasda3 ---------------------------
Begin partition 3
End partition 3, end of minidisk
The key difference between a CMS minidisk and a cdl minidisk, from a
boot loader point of view, is that for cdl, the entire bootable program is
contained at the beginning of the disk, prior to the start of
any partition. It is interrupted by the volume label, but otherwise
it is contiguous. For a CMS minidisk, the bootable program, with the
exception of the first two IPL records, is stored at the end of the disk.
It is stored after the CMS file system ends but before the minidisk ends.
CMS knows to leave this area alone when writing files. It is only
read during an device IPL and it is only written when applying maintenance
to the CMS nucleus.
Logically, it can be thought of as a continuation of interrupted
/dev/dasda. But physically, Linux treats it as the tail end of the
only partition, /dev/dasda1. In order to boot Linux from a CMS minidisk,
the file systems (mke2fs, mkreiserfs, etc.) have to be taught to leave
this area alone and the boot loader (zipl) has to be taught how to
write to it. Then CMS minidisks can be bootable under Linux, just like
cdl and ldl. There is nothing that makes CMS minidisks intrinsically
non-bootable. Linux just hasn't been taught how to use them
properly. CMS has been booting from CMS minidisks forever.
Currently, I can and do use CMS minidisks for all my DASD devices
except for the /boot partition. I don't use a CMS minidisk for my
/boot partition because I currently can't.
Now why do I want to use CMS minidisks? There are several reasons,
but the biggest reason is that I like to use the dasd_diag_mod driver.
Historically, this high performance driver could only be used with CMS
minidisks.
The dasd_diag_mod driver has been enhanced recently to support ldl
minidisks as well as CMS minidisks; so I currently use an ldl minidisk
for my /boot partition and everything else is a CMS minidisk. That has
reduced the priority of this request somewhat. But for a VM shop,
its nice to have all CMS minidisks for other reasons. For example, if
you try to access an ldl minidisk under CMS you get a "device error".
There's nothing wrong with the device. CMS just doesn't understand the
format.
Did I answer all your questions? Or do you still have more?
The stuff about the label record overlapping the superblock doesn't
make sense to me. It sounds like you think the label record resides
within the partition that mke2fs is trying to format. It doesn't.
As the above diagrams illustrate, it resides in the overhead section of
the disk before the partition starts.
Just before hitting "Send", I checked the bug log one more time and saw
another update. A kernel patch to respect the RECOMP area by reducing
the size of the partition seen by the file system sounds like a very
elegant solution. That fixes the problem in one place, instead of in
every supported file system. If the kernel people will accept that, that
will be wonderful. That leaves the update to zipl as the only remaining
barrier to full exploitation of CMS minidisks.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
