[gpfsug-discuss] Lost disks

Oesterlin, Robert Robert.Oesterlin at nuance.com
Wed Jul 26 18:45:35 BST 2017


One way this could possible happen would be a system is being installed (I’m assuming this is Linux) and the FC adapter is active; then the OS install will see disks and wipe out the NSD descriptor on those disks. (Which is why the NSD V2 format was invented, to prevent this from happening) If you don’t lose all of the descriptors, it’s sometimes possible to manually re-construct the missing header information - I’m assuming since you opened a PMR, IBM has looked at this. This is a scenario I’ve had to recover from - twice. Back-end array issue seems unlikely to me, I’d keep looking at the systems with access to those LUNs and see what commands/operations could have been run.

Bob Oesterlin
Sr Principal Storage Engineer, Nuance




From: <gpfsug-discuss-bounces at spectrumscale.org> on behalf of Mark Bush <Mark.Bush at siriuscom.com>
Reply-To: gpfsug main discussion list <gpfsug-discuss at spectrumscale.org>
Date: Wednesday, July 26, 2017 at 12:29 PM
To: "gpfsug-discuss at spectrumscale.org" <gpfsug-discuss at spectrumscale.org>
Subject: [EXTERNAL] [gpfsug-discuss] Lost disks

I have a client has had an issue where all of the nsd disks disappeared in the cluster recently.  Not sure if it’s due to a back end disk issue or if it’s a reboot that did it.  But in their PMR they were told that all that data is lost now and that the disk headers didn’t appear as GPFS disk headers.  How on earth could something like that happen?  Could it be a backend disk thing?  They are confident that nobody tried to reformat disks but aren’t 100% sure that something at the disk array couldn’t have caused this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20170726/f8fec8fd/attachment.htm>


More information about the gpfsug-discuss mailing list