Of course, I am sure everyone here realizes hat this problem cries out for a CMS Pipelines solution......now, where did I leave those manuals explaining the contents and layout of a VTOC....?


Rick Troth wrote:
On Fri, 30 Nov 2007, Stracka, James (GTI) wrote:

If you format the first couple of cylinders, it would probably fool the
kernel, but then the disk only APPEARS to be properly formatted to
z/Linux.  If the owner of the z/Linux guest does not remember to
reformat it after it is given to the guest, they could easily forget
that most if it is still unformatted.  They might even get far enough to
pvcreate it, and add it to a VG, only to find out when they run mkfs
that it is mostly bad.

Correct.
You can format the first cylinder of ECKD
to simply avoid the error messages.  You then must follow with
'dasdfmt' after Linux comes all the way up.

At BEST, because the labels and fake VTOC only show a disk of a few
cylinders, the remaining space might be ignored.   At worst, you'd get
the error messages again.  We know dasdfmt issues some kind of call to
return device geometry through the kernel, but whether that's used only
for formatting, or by the kernel itself, is not clear.

I'm confident that the kernel gets sizing info
from the device, not from the label.

If you CMS format the disk, it is good enough for the kernel not to
issue the error messages, but still reports bad whenever you run a
z/Linux utility against it.

That makes sense
because the remainder is not low-level formatted into 4K blocks.
Either CMS FORMAT (of more than one cyl) or 'dasdfmt' will be needed
to block out the rest of the disk.  No way around that.

If it helps explain things,
consider that FBA (eg: 9336, 3370, or VDISK) does not need this
because it is already blocked.  Same goes for SAN.

Our z/Linux guru had a look at the dasdfmt utility source code.  It
doesn't really DO anything itself, it uses an "ioctl" call to the kernel
driver to perform the actual formatting.  The channel programs that do
that are all in the kernel.

Interesting.
Not surprising.  Good point to know.

-- R;

--
DJ

V/Soft
  z/VM and mainframe Linux expertise, training,
  consulting, and software development
www.vsoft-software.com

Reply via email to