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;
