On 6/8/06, James Melin <[EMAIL PROTECTED]> wrote:
So, even though the VM image sees the disk as RO via the CP link, when Linux comes up, it does NOT see these as RO by default, even though FSTAB has the active disk mounted RO. the contents of /proc/dasd/devices never shows the RO linked disks as being R/O even though they are from a VM perspective. So the question I am asking is WHY?
Because the DASD architecture does not have a means to tell the host that someone has flipped the "write disable" switch on the device. There may be ways to tell (call the operator, webcam, CP Q LINK) but that is not architecture and may not work for each situation. The option to just try to write something did not seem very wise. But you can tell the kernel not to write to the disk using the (ro) option in the dasd= kernel parameter with older releases, and through the 'readonly' entry in the sysfs portion for the device (before you set it online). That shows like this: 0.0.0154(DIAG) at ( 94: 12) is dasdd : active at blocksize: 4096, 45000 blocks, 175 MB 0.0.0153(ECKD) at ( 94: 16) is dasde : active at blocksize: 4096, 45000 blocks, 175 MB 0.0.0155(ECKD) at ( 94: 20) is dasdf (ro): active at blocksize: 4096, 45000 blocks, 175 MB This makes the driver not retry the writes but simply reject before trying it. But the fact that the disk device is R/O does not yet tell the block device that the mount should be R/O so when you mount a disk it will still try to mark it "not clean" in case something happens before unmounting it. As Ronald suggested, using the blockdev command you can make the block device aware and it will make it a ro mount (with warning msg) as shown here (note the device is dasdf1 rather than dasdf). lrobv1:/mnt # blockdev --setro /dev/dasdf1 lrobv1:/mnt # mount /dev/dasdf1 /mnt/0155 mount: block device /dev/dasdf1 is write-protected, mounting read-only Hope this clarifies the situation. Rob PS With Linux retrying the write and the updated blocks being in page cache, you may not immediately notice what is going on. One can waste an entire night trying to understand why file transfer would fail after so many MB (eventually the data gets discarded and is seen as corrupted disk). -- Rob van der Heij Velocity Software, Inc http://velocitysoftware.com/ ---------------------------------------------------------------------- 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
