Re: [parted-devel] [Parted-maintainers] Debian Bug #578097: No support for CMS-formatted disks

[Stephen Powell]

On Thu, 16 Dec 2010 07:30:14 -0500 (EST), Jim Meyering wrote:
> Stephen Powell wrote:
>> ... do you have an s390 environment in which to test?
> 
> Yes, if an s390x will do.  On one, uname -a reports this:
> Linux xxx 2.6.32-19.el6.s390x #1 SMP Tue Mar 9 19:03:48 EST 2010 s390x s390x 
> s390x GNU/Linux

I am treating s390 and s390x as synonymous for purposes of this discussion.
In fact, in Debian, the implementation is a hybrid one.  The kernel space
is 64-bit (runs an s390x kernel) but the user space is 31-bit (uses s390
packages in 31-bit mode).

>> Does it have both CKD and FBA DASD?
>> Does it run as a guest under z/VM?  Does your
>> system have the DIAG driver?  Do you have
>> access to a CMS system from which you can FORMAT and/or
>> RESERVE the disks in CMS format?  The answer might not be
>> "yes" to all those questions, and getting such an environment
>> will take time.
> 
> I don't know, for any of the above.
> If you describe how to determine the answer
> in a way that is easy to automate, the goal
> would be to run a script that checks for required
> pieces and then runs whichever tests it can.

You can tell what the DASD type is by a combination of

   cat /proc/dasd/devices

and poking around in the sysfs file system.  For example:

   address@hidden:~$ cat /proc/dasd/devices
   0.0.0200(DIAG) at ( 94:     0) is dasda       : active at blocksize: 4096, 
540000 blocks, 2109 MB
   0.0.0201(ECKD) at ( 94:     4) is dasdb       : active at blocksize: 4096, 
13500 blocks, 52 MB
   0.0.0202(DIAG) at ( 94:     8) is dasdc       : active at blocksize: 4096, 
90000 blocks, 351 MB
   0.0.0203(DIAG) at ( 94:    12) is dasdd       : active at blocksize: 4096, 
90000 blocks, 351 MB
   address@hidden:~$

(The output of the above command shows devices that are online, but not
necessarily mounted.)  The output shows the correspondence between s390
device numbers (0.0.xxxx, where xxxx is the hex device number), kernel-space
major and minor device numbers, user-space block special file names
(/dev/dasda, etc.) and drivers (dasd_eckd_mod, dasd_fba_mod, dasd_diag_mod).
It also shows the effective block size, number of blocks, and size in MB.
In the above example, three of the four DASD devices are using the DIAG
driver and one is using the ECKD driver.  If the ECKD driver is being used,
it is CKD DASD.  If the FBA driver is being used, it is FBA DASD.  If the
DIAG driver is being used, it could be either CKD or FBA DASD.  You can't
tell from here.  For that, you need to probe the sysfs pseudo file system.
For example:

   address@hidden:~$ cat /sys/bus/ccw/devices/0.0.0200/devtype
   3390/0a
   address@hidden:~$

If the first four characters of output are 3370 or 9336, it's FBA DASD.
Otherwise, it's CKD DASD.

Make sure that your Linux kernel contains the FBA patch.  Look at fs/partitions/
ibm.c, C function ibm_partition.  About 40 lines down from the beginning
of the function, you should see logic similar to the following:

   /*
    * Special case for FBA disks: label sector does not depend on
    * blocksize.
    */
   if ((info->cu_type == 0x6310 && info->dev_type == 0x9336) ||
       (info->cu_type == 0x3880 && info->dev_type == 0x3370))
           labelsect = info->label_block;
   else
           labelsect = info->label_block * (blocksize >> 9);

If that code isn't in there, you will need to update your kernel.  If your
kernel doesn't have this fix, then parted and the Linux kernel will report
different starting sector numbers and number of sectors for FBA DASD in CMS
RESERVED format under certain conditions, and the kernel will be wrong
and parted will be right!  See Debian bug report 582281
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=582281) for details.

If I recall correctly, upstream kernel source 2.6.32-20 was the first
to add this fix; so I don't know about your 2.6.32-19.el6.s390x
distribution kernel.  Unless it contains distribution specific patches
to fix this problem, it probably won't work right.

The basic testing idea is to compare the starting sector number and
number of sectors for the partition as reported by parted and
the starting sector number and number of sectors reported by the
Linux kernel via the sysfs file system.  You can also compare parted's
reported file system type vs. what is reported by "mount" (if the
partition is mounted) or "cat /proc/swaps" (if the partition is an
active swap partition).  For example, on my "debian3" test system,
I have four DASD devices, all 3390 minidisks, formatted by CMS with
a blocksize of 4096, and processed with the CMS RESERVE command.
The number of cylinders varies from one disk to another:

   address@hidden:~$ su
   Password: ********
   debian3:/home/steve# cd
   debian3:~# parted /dev/dasda unit s print free
   Model: IBM S390 DASD drive (dasd)
   Disk /dev/dasda: 4320000s
   Sector size (logical/physical): 512B/4096B
   Partition Table: dasd

   Number  Start  End       Size      File System  Flags
    1      4552s  4319991s  4315440s  ext3

   debian3:~# cat /sys/bus/ccw/devices/0.0.0200/block/dasda/size
   4320000
   debian3:~# cat /sys/bus/ccw/devices/0.0.0200/block/dasda/dasda1/start
   4552
   debian3:~# cat /sys/bus/ccw/devices/0.0.0200/block/dasda/dasda1/size
   4315440
   debian3:~# mount
   /dev/dasda1 on / type ext3 (rw,errors=remount-ro)
   tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
   proc on /proc type proc (rw,noexec,nosuid,nodev)
   udev on /dev type tmpfs (rw,mode=0755)
   tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
   devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
   /dev/dasdb1 on /boot type ext3 (rw)
   /dev/dasdc1 on /home type ext3 (rw)
   debian3:~# cat /proc/swaps
   Filename                                Type            Size    Used    
Priority
   /dev/dasdd1                             partition       359580  0       -1

(Note that on most systems one must be root to directly access a block
special file, as parted does.)  The more DASD types (CKD or FBA), DASD
formats (cdl, ldl, CMS non-reserved, and CMS reserved), and DASD driver
(ECKD, FBA, and DIAG) combinations you test, the better.  Also, all block
sizes (512, 1024, 2048, and 4096) should be tested.  In my development work
I tested every combination supported by the Linux kernel with all block
sizes.  Whether you want to be that thorough or just "spot check" certain
combinations is up to your discretion.  Here are the combinations supported
by the Linux kernel:

   DASD type     DASD format     DASD driver
   ---------     -----------     -----------
   CKD           cdl             ECKD
   CKD           ldl             ECKD
   CKD           ldl             DIAG
   CKD           CMS NR          ECKD
   CKD           CMS NR          DIAG
   CKD           CMS R           ECKD
   CKD           CMS R           DIAG
   FBA           CMS NR          FBA
   FBA           CMS NR          DIAG
   FBA           CMS R           FBA
   FBA           CMS R           DIAG

Prior to these enhancements, parted supported only the first two
combinations.  Actually, you can further break down ldl into ldl format
1 and ldl format 2, if you want to get even more aggressive in your
testing.  You need an older version of s390-tools to create an ldl format 1
disk, though.  All newer releases of s390-tools create ldl format 2 disks.
I don't know when the switch was made, but I do know that 1.6.2 creates
ldl format 1 and 1.8.3 creates ldl format 2.  Also, parted should not show
any free space except when using cdl format.  If my logic is correct,
every sector on the disk should be covered by a metadata partition or
by the single implicit regular partition.

One way to determine if you are running under z/VM is to look
at the boot messages via "dmesg|less" and search for "VM".  You should
find a message fairly near the top that looks something like this:

   setup: Linux is running as a z/VM guest operating system in 64-bit mode

Unless you are running as a guest operating system under z/VM, you can't
use the DIAG driver.  Also, without a z/VM system you won't have the
CMS operating system available (in another virtual machine, of course)
to create minidisks in CMS format.  Eliminate the DIAG driver and the
CMS disk format, and you've eliminated *all* the new supported combinations;
so all you can really do is regression testing to make sure I haven't
broken anything that used to work.
> 
> The best is to put into version control some script
> that someone with the right equipment can run via "make check"
> (probably with a couple envvars specifying things that cannot
> or must not be guessed, like the name of a partition to clobber,
> or a device to format).

I'm afraid I don't know much about make.  I never invoke make directly,
except "make menuconfig" when configuring a custom kernel.  For everything
else, I use a higher-level tool that invokes make "under the covers".
For example, to compile a custom kernel and create a Debian package file
for the kernel I use

  make-kpkg ...

and to compile my changes to parted and produce a Debian package file I use

  dpkg-buildpackage ...

(I run Debian, and these are Debian-specific tools.)  The point is, I'm
not familiar with make; so I'll leave the writing of a script that interfaces
with "make check" up to you.  You're the expert there.

> 
> But if it's really not feasible, I'm sure we'll find a reasonable
> middle ground.

That depends mostly on whether or not you have a system to test with that
runs as a guest of z/VM.  If you don't, I, or someone else, will have
to do your testing for you.

-- 
  .''`.     Stephen Powell    
 : :'  :
 `. `'`
   `-