$)C<font size=2 face="sans-serif">Jonathan,</font><br><br><font size=2 face="sans-serif">Regarding </font><br><br><tt><font size=2>>> Thing is GPFS does not look at the NSD descriptors

that much. So in my<br>>> case it was several days before it was noticed, and only then

because I >> rebooted the last NSD server as part of a rolling upgrade of GPFS.

I<br>>> could have cruised for weeks/months with no NSD descriptors if

I had not<br>>> restarted all the NSD servers. The moral of this is the overwrite

could<br>>> have take place quite some time ago.</font></tt><br><br><font size=2 face="sans-serif">While GPFS does not normally read the

NSD descriptors in the course of performing file system operations, as

of 4.1.1 a periodic check is done on the content of various descriptors,

and a message like</font><br><br><tt><font size=2>[E] On-disk NSD descriptor of <disk> is valid

but has a different ID. ID in cache is <NSD ID> and ID on-disk is<NSD

ID></font></tt><br><br><font size=2 face="sans-serif">should get issued if the content of

the descriptor on disk changes.</font><br><br><br><font size=2 face="sans-serif">Regards, The Spectrum Scale (GPFS) team<br><br>------------------------------------------------------------------------------------------------------------------<br>If you feel that your question can benefit other users of  Spectrum

Scale (GPFS), then please post it to the public IBM developerWroks Forum

at <a href="https://www.ibm.com/developerworks/community/forums/html/forum?id=11111111-0000-0000-0000-000000000479"><font size=2 face="sans-serif">https://www.ibm.com/developerworks/community/forums/html/forum?id=11111111-0000-0000-0000-000000000479</a><font size=2 face="sans-serif">.

<br><br>If your query concerns a potential software error in Spectrum Scale (GPFS)

and you have an IBM software maintenance contract please contact  1-800-237-5511

in the United States or your local IBM Service Center in other countries.

<br><br>The forum is informally monitored as time permits and should not be used

for priority messages to the Spectrum Scale (GPFS) team.</font><br><br><br><br><font size=1 color=#5f5f5f face="sans-serif">From:      

 </font><font size=1 face="sans-serif">Jonathan Buzzard <jonathan@buzzard.me.uk></font><br><font size=1 color=#5f5f5f face="sans-serif">To:      

 </font><font size=1 face="sans-serif">gpfsug main discussion

list <gpfsug-discuss@spectrumscale.org></font><br><font size=1 color=#5f5f5f face="sans-serif">Date:      

 </font><font size=1 face="sans-serif">07/27/2017 06:58 AM</font><br><font size=1 color=#5f5f5f face="sans-serif">Subject:    

   </font><font size=1 face="sans-serif">Re: [gpfsug-discuss]

Lost disks</font><br><font size=1 color=#5f5f5f face="sans-serif">Sent by:    

   </font><font size=1 face="sans-serif">gpfsug-discuss-bounces@spectrumscale.org</font><br><hr noshade><br><br><br><tt><font size=2>On Wed, 2017-07-26 at 17:45 +0000, Oesterlin, Robert

wrote:<br>> One way this could possible happen would be a system is being<br>> installed (I!/m assuming this is Linux) and the FC adapter is active;<br>> then the OS install will see disks and wipe out the NSD descriptor

on<br>> those disks. (Which is why the NSD V2 format was invented, to prevent<br>> this from happening) If you don!/t lose all of the descriptors, it!/s<br>> sometimes possible to manually re-construct the missing header<br>> information - I!/m assuming since you opened a PMR, IBM has looked

at<br>> this. This is a scenario I!/ve had to recover from - twice. Back-end<br>> 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. I would concur that this is the most likely scenario; an install where for whatever reason the machine could see the disks and they are gone.

I<br>know that RHEL6 and its derivatives will do that for you. Has happened<br>to me at previous place of work where another admin forgot to de-zone a<br>server, went to install CentOS6 as part of a cluster upgrade from<br>CentOS5 and overwrote all the NSD descriptors.<br><br>Thing is GPFS does not look at the NSD descriptors that much. So in my<br>case it was several days before it was noticed, and only then because I<br>rebooted the last NSD server as part of a rolling upgrade of GPFS. I<br>could have cruised for weeks/months with no NSD descriptors if I had not<br>restarted all the NSD servers. The moral of this is the overwrite could<br>have take place quite some time ago.<br><br>Basically if the disks are all missing then the NSD descriptor has been<br>overwritten, and the protestations of the client are irrelevant. The<br>chances of the disk array doing it to *ALL* the disks is somewhere<br>around )$ IMHO.<br><br>JAB.<br><br>-- <br>Jonathan A. Buzzard                

Email: jonathan (at) buzzard.me.uk<br>Fife, United Kingdom.<br><br>_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at spectrumscale.org<br></font></tt><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss"><tt><font size=2>http://gpfsug.org/mailman/listinfo/gpfsug-discuss</font></tt></a><tt><font size=2><br></font></tt><br><BR>