Partman/partconf and S/390; is this a "wishlist" bug for partman?
As near as I can tell, S/390 still uses partconf, and it and m68k are
the only architectures to do so.
Something I think we should think about--although not for the d-i or
sarge releases, probably--is to get S/390 moved over to partman (if I
understand correctly that partman's functionality is a superset of
partconf's).
We should also get better handling for FBA disks into the S/390
installer.
(For those of you unfamiliar with S/390: most disks, and the only disks
that MVS/OS390/zOS support, are ECKD (Extended Count Key Data); FBA
(Fixed Block Architecture) is much more like disk everywhere else in the
world, in that it's just a range of 512-byte blocks. It doesn't get
much attention because S/390 disk is almost always presented as ECKD
disk (even though these days all the ECKD stuff is emulated and it's
really sitting on a big array of SCSI disks, which are FBA devices))
It's not a big deal right now, because the only use most people have for
FBA is swap on VDISK (virtual DASD which comes out of VM's page
space--this has the advantage that if there's physical memory available
on the box, it's in memory and thus swap to it isn't a lot slower than
real memory access, and if memory is tight, VM handles paging it out to
disk automatically), and it's not too much hassle to do this manually.
However, with z/VM 5.1, due out soon, z/VM will be able to transparently
present Fibre-Channel attached SCSI devices as FBA devices. That's
going to make life a lot easier for Linux guests (using FCP SCSI is
possible, but very painful, right now) because some annoying size
restrictions on ECKD disks are greatly ameliorated with the emulated FBA
in z/VM 5.1 (the largest ECKD disk is currently a 3390-27, which is
32760 cylinders, which comes out to about 28GB--z/VM 5.1 will support
emulated FBA up to 384GB). Also, the ECKD scheme wastes an awful lot of
disk space on architectures that like 4K blocks. The capacity of a
Model 3 (3339 cylinders), which is still the standard DASD size and what
most shops have all their volumes formatted as, is about 2.8 GB, but
Linux only sees 2.3 GB of that because of space wasted on each track
(which implies LVM if you need more than 2.3GB in a single filesystem,
which is *really* annoying).
There's a third disk access method, DIAG, which is also supported in the
kernel but not in the installer, and it should be. That's a feature
that only works under VM, with disks that you have specially RESERVEd
under CMS, and it involves basically letting VM manage disk resources
and I/O access for its guests via a VM interface rather than worrying
about passing I/O channel commands. This generally lets it get slightly
better performance on FBA devices, although usually not for CKD
devices. It's the best way to implement swap-on-VDISK, which is the
primary use for it. The Linux DASD driver, when you hand it a disk,
assuming it's got all three methods built into it (the stock Debian
kernel does), knows which kind of access to use. So I don't think that
from an application perspective anything would need to change much to
support all three. However, partconf currently refuses to touch
anything that isn't CKD.
The reason why is fairly simple: the native S/390 partitioning tool,
fdasd, which partconf uses, only works with ECKD.
But that's OK. If you have a plain old FBA device, you should use the
raw disk device: /dev/dasdd (or, in devfs terms, /dev/dasd/0153/disc).
If you have a RESERVEd minidisk (i.e. DIAG-accessed), the RESERVEd space
will show up as part1 (i.e., /dev/dasdd1 or /dev/dasd/0153/part1). So
although you cannot partition a disk of either sort, you don't need to
in order to use it.
The point of this rather rambling note is just that Debian on S/390 and
S/390x needs better handling of FBA and DIAG disks at install time to be
ready for z/VM 5.1 (which would also let us support swap-on-VDISK
natively, without having to do any manual steps, which would be a
plus). I think this should be accompanied by a transition entirely to
partman but I don't understand the various pieces of disk management
well enough to be sure. Before I open this up as a "wishlist" bug I
want to be sure that I'm opening it in the right package. Should this
be a partman wishlist bug?
Adam
Reply to: