>>> On 10/3/2014 at 01:22 PM, Neale Ferguson <[email protected]> wrote: > A topic that has already been discussed but may be some more information. > > I have a minidisk 0200 that has been CMS formatted: > > [root@rh7cn1 ~]# cat /proc/dasd/devices > : > 0.0.0200(ECKD) at ( 94: 16) is dasde : active at blocksize: 4096, > 90000 blocks, 351 MB > > I note it already appears to have a partition on it! > > [root@rh7cn1 ~]# cat /proc/partitions > major minor #blocks name > : > 94 16 360000 dasde > 94 17 359988 dasde1
Yes, that's the default behavior for FBA devices, and has been for a very long time. > Just for laughs I try and repartition the device: > > [root@rh7cn1 ~]# fdasd /dev/dasde > > fdasd error: Unsupported disk format > /dev/dasde is not formatted with z/OS compatible disk layout! Which would be expected for an FBA device. > Strange. Okay, let's do a low-level format: > > [root@rh7cn1 ~]# dasdfmt /dev/dasde > Please enter the blocksize of the formatting [4096]: > Drive Geometry: 500 Cylinders * 15 Heads = 7500 Tracks > > I am going to format the device /dev/dasde in the following way: > Device number of device : 0x200 > Labelling device : yes > Disk label : VOL1 > Disk identifier : 0X0200 > Extent start (trk no) : 0 > Extent end (trk no) : 7499 > Compatible Disk Layout : yes > Blocksize : 4096 > > --->> ATTENTION! <<--- > All data of that device will be lost. > Type "yes" to continue, no will leave the disk untouched: yes > Formatting the device. This may take a while (get yourself a coffee). > dasdfmt: (invalidate first track) IOCTL BIODASDFMT failed. (Input/output > error) Now that looks like a bug. > Yech! Here's what /var/log/messages has to say - > > [root@rh7cn1 ~]# tail -20 /var/log/messages > : > Oct 3 13:04:48 rh7cn1 kernel: dasd-eckd 0.0.0200: An error occurred in the > DASD device driver, reason=09 > Oct 3 13:04:48 rh7cn1 kernel: dasd(eckd): I/O status report for device > 0.0.0200: > dasd(eckd): in req: 000000002d5c3e90 CC:01 FC:04 AC:00 SC:17 DS:02 CS:00 > RC:0 > dasd(eckd): device 0.0.0200: Failing CCW: 000000002d5c3f98 > dasd(eckd): Sense(hex) 0- 7: 80 00 00 00 00 00 00 01 > dasd(eckd): Sense(hex) 8-15: 00 00 00 00 00 00 00 00 > dasd(eckd): Sense(hex) 16-23: 00 00 00 00 00 00 00 00 > dasd(eckd): Sense(hex) 24-31: 00 00 40 80 00 00 00 00 > dasd(eckd): 24 Byte: 0 MSG 1, no MSGb to SYSOP > Oct 3 13:04:48 rh7cn1 kernel: dasd(eckd): Related CP in req: > 000000002d5c3e90 > dasd(eckd): CCW 000000002d5c3f90: E7400040 2D5C3FA8 DAT: 00a00000 00000000 > 00000000 00c40000 00000000 00000000 00000000 00000000 > dasd(eckd): CCW 000000002d5c3f98: 47400010 2D5C3FE8 DAT: 03800001 00000000 > 00000000 00000008 > dasd(eckd): CCW 000000002d5c3fa0: 1D200008 2D5C3FF8 DAT: 00000000 01000000 > Oct 3 13:04:48 rh7cn1 systemd-udevd: inotify_add_watch(7, /dev/dasde1, 10) > failed: No such file or directory > > Command reject on a locate record??!! I do note that there was an APAR for > z/VM 5.3 that dealt with the x'e7' CCW and command reject on guest virtual > machines, but I dare say that's been in z/VM 6.2 from the get-go. There are > no messages on the OPERATOR console indicating z/VM has detected a real I/O > error. The only other twist is that I'm running on a zPDT. I thought a prefix > CCW contained the define-extend and locate-record information making the > x'47' > CCW redundant, but I'm no expert with these new fangled prefix thingies. > > Other details: > 1. Kernel: 3.10.0-123.8.1.el7.s390x > 2. s390utils: 1.23.0-12 > 3. z/VM: 6.2 1101 Mark Post ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
