On Wed, Jul 09, 2008 at 09:20:52AM -0700, Stephen Powell wrote:
> The structure I sent to you maps the CMS label record. For FBA
> devices, the label record is the second 512-byte block of the
> minidisk. For CKD devices, the label record is cylinder 0, track 0,
> record 3, which would be the third block of the minidisk. The first
> four bytes of the CMS label record are always "CMS1" in EBCDIC.
> That would be X'C3D4E2F1'.
So here's the problem. The 3rd block of the minidisk (assuming 512
byte blocks), overlaps with the the ext2/3/4 superblock, which lives
at byte offset 1024 through 2047. So for CKD devices, it's impossible
for the CMS label record and ext2/3/4 to co-exist. Thats a
fundamental property of the ext2/3/4 filesystem.
This is the fundamental problem with in-band storage of partitioning
information, and this is one of the places where the mainframe
designers seem to have really screwed up. With Linux, and pretty much
all Unix systems, you have the whole disk device /dev/sda, and on that
whole disk device, there is a partition table. That partition table
is read by OS, which tells it how to divide up the disk, and then each
filesystem gets to live in its own partition --- i.e., /dev/sda1,
/dev/sda2, etc. There are conventions that the first 1024 bytes
should be left alone for the initial blocks of a boot loader, but
other than that, the filesystem has free run of its partition --- i.e,
it can use the entire disk of /dev/sda1.
To have a scheme where you have an RECOMP part of the disk which other
filesystems need to somehow have magic knowledge that they need to
avoid, and then to put the partition table someplace strange such as
offset 1k, is from the point of view of Linux and its Unix bretheren,
complete madness.
So if thats the way things really work in the mainframe land, I think
there's not much e2fsprogs can do to let a RECOMP partition co-exist
with an ext2/3/4 filesystem. We could read the CMS label at offset
1024 from the beginning of the disk (which is where the 3rd 512 byte
block would start), and we could avoid overwriting the RECOMP space by
artifically restricting the size of the ext2/3/4 filesystem. However,
when we then write out the ext2/3/4 superblock, we will overwrite the
CMS label, which will presumably make it impossible for the IPL loader
from finding the RECOMP space, since I assume it must read the CMS
label to figure out where the RECOMP space begins and where to start
IPL'ing the boot program.
Regards,
- Ted
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
