So ...
Our VM guy gave us a chunk of SCSI disk (SAN disk) to work with.
VM is playing the EDEV game so that this is presented as a 9336,
which looks to CMS and Linux and any other guest as fixed-block IBM
via ye olde beloved SSCH style I/O. Ahhhhhhhh.......
No tracks to format. No cylinder geometry to worry about.
Just pure, raw, storage!!! DDR reduces to 'dd', and
complete disk image backups are easy and portable.
Now ... I allocated a minidisk from the volume. Looks to Linux
like FBA, and goes through that device driver (DASD), so it can
only have three partitions. But how do I create the partitions?
Turns out that 'fdasd' is most unhappy with this disk,
but 'fdisk' seems to grok it. Results are weird. (see below)
I'll share what I've found thus far.
This has taken a little longer than I would have hoped,
and I wonder if some kind of FBA/SCSI and partitioning kon-foo-zhun
caused my system to crash. (It shut down fine, but the root FS
was totally shot upon re-IPL. But I had not fiddled with root!)
Because of the trouble getting 'fdisk' to report correctly
about partitions I created, I deleted and re-created them
several times. I am wondering if so many partition delete/add cycles
horqued the kernel's partition table causing the root slam.
Certainly it "should not happen". But when you're the victim,
and you don't know the code, you're always suspicious! ;-)
I re-built the system, reIPLed, and tried again.
IT IS BOOTABLE. This is a good sign. Working from the prior
3390-based root (after recovery!), I reserved a few meg at the
start of the disk, instructing 'fdisk' to create the first partition
some 9M in. Second partition is right after that, and third follows
consuming the rest of the disk. I figure that SCSI disk I/O paths
in the kernel would give me FIFTEEN partitions if I wanted. But again,
this is via DASD, so we're limitted to three. No biggie.
Here's the weird part.
(Not the IPL but the response from 'fdisk' after that.)
rmtlinux # hcp ipl fba clear
... cool, huh? 'IPL FBA' ... hah! ...
... lots o boot-time stuff omitted ...
rmtlinux # fdisk /dev/dasdh
Command (m for help): p
Disk /dev/dasdh: 166 MB, 166625280 bytes
16 heads, 128 sectors/track, 158 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes
Device Boot Start End Blocks Id System
/dev/dasdh1 4 23 20480 83 Linux
Partition 1 has different physical/logical endings:
phys=(534, 15, 0) logical=(22, 15, 128)
Partition 1 does not end on cylinder boundary.
/dev/dasdh2 24 62 39936 83 Linux
Partition 2 has different physical/logical endings:
phys=(573, 15, 0) logical=(61, 15, 128)
Partition 2 does not end on cylinder boundary.
/dev/dasdh3 64 158 97280 83 Linux
Partition 3 has different physical/logical endings:
phys=(669, 15, 0) logical=(157, 15, 128)
Partition 3 does not end on cylinder boundary.
Command (m for help): q
rmtlinux #
I COULD NOT convince 'fdisk' to make these complaints go away.
Is the problem in what the DASD driver reports to 'fdisk'?
This code has been hammered time and again with "real SCSI".
What is the problem with SCSI is presented as FBA via the DASD driver?
Maybe DASD always reports c/h/s geometry for 3390 (or even 3380?)
but fails to report good numbers for 9336 and friends? Curious.
The disk is usable: 20M, 40M, and just under 100M, three partitions.
I've reIPLed a number of times, and aside from a network stall
(which happens on this host occasionally even on the 3390 root)
it works quite nicely. There's still this annoying noise from 'fdisk',
plus my mysterious clobbering of root (which COULD be unrelated).
Thoughts?
Next thing I want to do is eyeball this thing from the
non-EDEV SCSI view. But that will probably take a while.
And why do I get this sick feeling that Neale has been here before?
-- R;
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
