The most obvious, but least likely are the simplest to detect. Sorry, I have no answers -- just diagnostic questions...
1) Is it possible that there were any minidisk definition overlaps? Do you a directory management product to guard against that? If so, are there any trap doors left open (e.g. full extent minidisks that could have been linked R/W by another)? If not, does DISKMAP or DIRMAP report any OVERLAPs? 2) Could an external or guest system have written to the disks (i.e another z/VM system, z/OS system etc. sharing the same set of DASD)? 3) Could another user have linked to one or more of the minidisks R/W? 4) Were here any hardware log errors? And just for fun, was it ONLY LVMs that were blow away, or was it the 200 (IPL) and 201 (/usr or swap) disks, too? BTW, from another listserver discussion: 'Linux' is a trademark or Linus Torvalds. It is not supposed to be prefaced or appended by anything. z/Linux, and zLinux violate the trademark. 'Linux for System z', while verbose does not. We should respect his trademark when using Linux publically. I *believe* that IBM may own the trademark for z/anything (not 100% certain on that). Mike Walter Hewitt Associates The opinions expressed herein are mine alone, not my employer's. "Paul Raulerson" <p...@raulersons.com> Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> 10/30/2009 12:23 AM Please respond to "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> To IBMVM@LISTSERV.UARK.EDU cc Subject z/LInux, LVM, and minor disasters. I had to add some additional DASD to a Linux instance over the weekend, and for whatever reason, it turned into a disaster. Linux somehow or another decided to rearrange all the DASD and blew every single LVM I had on the machine. Just under half a terabyte of data went into some unrecoverable mode. I'm pretty careful about this, and just build ~100GB volumes using 3390-9 volumes. The mini-disk definitions are always ordered and new DASD gets higher, sequential numbering. I always start my minidisk assignments at 200, so 200 is the IPL disk, 201 is either /usr or swap, depending. 202 starts the data volumes. I wound up building a new instance, and installing a slightly updated version of Linux, then restoring all the data with Tivoli from a VTL. There was no permanent damage done, except to my ability to sleep at night. When I rebuilt the data partitions, I built them as RAID-0 partitions. (The Shark takes care of the real RAID, and I am not worried about data loss from that direction.) Has anyone else ran into this? -Paul The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
