bug-parted
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC/PATCH 0/2] support for CMS-formatted disks on the s/390 archite


From: Stephen Powell
Subject: Re: [RFC/PATCH 0/2] support for CMS-formatted disks on the s/390 architecture
Date: Wed, 21 Apr 2010 13:08:04 -0400 (EDT)

On Sat, 17 Apr 2010 16:42:44 -0400 (EDT), Jim Meyering wrote:
> Stephen Powell wrote:
>> On Sat, 17 Apr 2010 11:10:04 -0400 (EDT), Jim Meyering wrote:
>>>
>>> Thanks for preparing those.
>>> Can either of you outline a test for each that would fail before
>>> application of a patch and succeed after it?
>>
>> For the second problem, lack of recognition of CMS minidisks, the
>> above command will report ...
>> 
> 
> Can you provide or tell how to construct a minimal example image?
> 
> My goal is to write a portable shell script that triggers
> the flaw, and use that to show your fix solves the problem.

As promised earlier, here is the information you requested.
I have uploaded a number of files to my web site, as outlined below.

1. http://www.wowway.com/~zlinuxman/parted/ldl_console.log

   This is a Linux console log of the old version of parted (before
   the patches) attempting to use all four formats of ldl disk
   (block sizes 512, 1024, 2048, and 4096, respectively).
   Notice that the device was taken offline and brought back online
   again each time the dasdfmt/mke2fs sequence was
   run, but still parted did not recognize the file system on
   the disk except for the case of a block size of 4096, which is
   the only case where the hard-coded "start = 24" is correct.
   As a consequence, 12.3kB is listed as the start of the partition
   in every case, which is incorrect except for the case of a
   block size of 4096.  The Size column is also incorrect except
   for the case of a block size of 4096.

   This console log is from a Linux for s390 host running in a
   virtual machine under z/VM, as are all the Linux console logs.
   If you don't have z/VM, I assume that the Hercules emulator
   has some way of creating a one-cylinder 3390 dasd volume.

2. http://www.wowway.com/~zlinuxman/parted/cmsformat.log
   This is a console log from a VM/CMS system showing minidisks
   CMSDISKS 400-407 being formatted.  400-403 were formatted
   with a block size of 512, 1024, 2048, and 4096, respectively,
   and were not reserved.  404-407 were also formatted as above
   with a block size of 512, 1024, 2048, and 4096, respectively,
   and were also reserved.  There is no tool of which I am aware
   that can create CMS-formatted disks under Linux.  As far as
   I know, only the CMS operating system, a virtual-machine-only
   operating system that comes with z/VM, is capable of creating
   disks in the CMS format.  The virtual machine which did the
   formatting (MAINT, in this case) was running CMS and had the
   LNKNOPAS option in its directory entry, which is why CP did
   not prompt for any passwords.

   Note that very old versions of VM which have passed into the
   public domain, such as VM/370 release 6, can be legally run
   on Hercules without a license from IBM to do so.  These versions
   only run in 370 mode, but Hercules can emulate 370 mode.  However,
   versions of VM which are that old do not support the modern
   format of CMS minidisk.  These old versions of VM support only
   the CDF (Compatibility Disk Format) of CMS minidisk, which always
   has a block size of 800.  The Linux kernel only supports the
   EDF (Enhanced Disk Format) of CMS minidisk, which has a block
   size of 512, 1024, 2048, or 4096.  Therefore, don't count on
   using public domain versions of VM to create CMS minidisks
   for use with Linux for s390.

   Note: The CDF (Compatibility Disk Format) of CMS minidisk is not
   to be confused with the CDL (Compatibility Disk Layout) of
   DASD supported by the Linux kernel.  They are two completely
   different unrelated things.

3. http://www.wowway.com/~zlinuxman/parted/cms_console.log
   This is a console log from a Linux for s390 session showing
   the old version of parted (without the patches) trying to
   list the partitions of all eight formats of CMS minidisk.
   As you can see, it fails every time.

4. http://www.wowway.com/~zlinuxman/parted/new_ldl_console.log
   This is a console log from a Linux for s390 session showing
   the new version of parted (with the patches) trying to list
   the partitions of all four formats of ldl disk.  Note that
   it is successful as long as the disk is taken offline and
   brought online again after each dasdfmt/mke2fs sequence.
   I'm not sure why that's necessary, but I've discovered by
   trial and error that it is.

   I eliminated the error messages about overlapping partitions
   by means of a crude hack: I set vtoc_end equal to 2 in the
   dasd_alloc_metadata internal subroutine of libparted/labels/dasd.c.
   This forces the metadata to be interpreted as the first three
   512-byte logical sectors only (0-2).  This eliminates the
   overlap even in the worst case scenario, which is an ldl disk
   or a non-reserved CMS disk with a block size of 512.  However,
   listing the free space will show free space where there
   shouldn't be any in every other case.  This is just a temporary
   "finger in the dike" solution.  The permanent fix will be to
   figure out how to do in dasd_alloc_metadata what was done in
   dasd_read.  I'll turn my attention to that shortly,
   but first I wanted to supply you with the information that you
   requested.

5. http://www.wowway.com/~zlinuxman/parted/new_cms_console.log
   This is a console log of a Linux for s390 session showing the
   new version of parted (with the patches) trying to list the
   partitions of all eight formats of CMS minidisk.  As you can
   see, it is successful.

6. http://www.wowway.com/~zlinuxman/parted/images.tar.gz
   If you don't have a VM/CMS system with which to create CMS-formatted
   minidisks, this gzipped tar file may be helpful to you.
   Expand it with "tar -xzf images.tar.gz"  This will create eight
   files starting with "cms" and ending with ".bin".  After "cms"
   comes the block size, and after the block size comes either "nr"
   (for non-reserved) or r (for reserved).  These are images dumped
   directly from /dev/dasde in my console log examples.  You might
   need to use chgrp and/or chown on the extracted files if the
   source user number and group number don't exist on your system or
   do not correspond to the user/group that you are currently using.
   To save space on my web site, I only dumped up through the last non-zero
   block.  Therefore, you will first have to format the disk with
   something like "dasdfmt -b xxxx -l TMP400 -d ldl", where xxxx
   is the block size, prior to restoring.  Then use dd to lay the
   original blocks back down again.  For example,

      dasdfmt -b 1024 -l TMP400 -d ldl /dev/dasde
      yes
      dd ibs=512 if=cms1024nr.bin obs=1024 of=/dev/dasde
      sync
      echo 0 >/sys/bus/ccw/devices/0.0.0400/online
      echo 1 >/sys/bus/ccw/devices/0.0.0400/online

   Note that ibs is always 512 for all eight cases, but obs varies
   depending on the disk block size.  You have to be root to do this,
   of course.  These images are only accurate for a one-cylinder
   3390 disk.  If you have any further questions, just ask.

   Now to turn my attention to the dasd_alloc_metadata problem.
   I just had an idea of how to fix it.  I'm going to try my idea
   this afternoon.

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]