[gpfsug-discuss] Removing LUN from host without unconfiguring GPFS filesystem

[Harold Morales]

Thanks Stephen and Jonathan for pointing this important things out. Now I
begin to understand the importance of mmimportfs/mmexportfs for operations
like the one I discuss here. Will let you know how it goes.



2018-01-22 4:57 GMT-05:00 Jonathan Buzzard <jonathan.buzzard at strath.ac.uk>:

> On 22/01/18 03:41, Stephen Ulmer wrote:
>
>> Harold,
>>
>> The way I read your question, no one has actually answered it fully:
>>
>> You want to put the old file system in cold storage for forensic purposes
>> — exactly as it is. You want the NSDs to go away until and unless you need
>> them in the future.
>>
>>
> Hum, I would have said I did answer it fully even if I didn't go into
> detail. The only in my view sensible approach is to do mmexportfs so that
> should you need access to the data then you can get to it by reimporting it
> using mmimportfs. In the interim you can unmap all the NSD's from the
> cluster without causing GPFS to go care in the slightest.
>
> Otherwise you are doing something that is in my view at the best fool
> hardy and more generally down right idiotic. Personally I would outright
> refuse to do it without someone else higher up signing a written disclaimer
> that I was not responsible should it all go pear shaped. Note that the
> mmexportfs takes a few seconds at most to complete, and likewise with the
> mmimport.
>
> I am however somewhat perplexed by the data integrity side of the issue.
> If you suspect the data is corrupt in the old file system then having it
> around for reference purposes is surely not going to help. What are you
> going to do mount it again to find the file is corrupt; how is that going
> to help?
>
> If you suspect that whatever method you used to move the files from the
> old file system to the new one may have introduced corruption, then I would
> suggest that the best way out of that is to do an rsync with the -c flag so
> that it takes an MD5 checksum of the files on both file systems. Once that
> is complete you can safely ditch the old file system completely knowing
> that you have recovered it as best as possible. You could probably kick a
> bunch of rsyncs of in parallel to speed this method up.
>
> In fact a "rsync -c" would be a gold standard of look it's absolutely the
> same on the old and new file systems and remove all doubts about the
> transfer introducing corruption. At that point if someone comes and says
> your transfer corrupted my files, you can with justification say they where
> corrupt in the old file system and I have done my best to transfer them
> over. Note if any user was deliberately creating MD5 collisions then they
> get everything they deserve in my view, and accidental collisions in MD5
> are about as likely as ħ.
>
>
> JAB.
>
> --
> Jonathan A. Buzzard                         Tel: +44141-5483420
> HPC System Administrator, ARCHIE-WeSt.
> University of Strathclyde, John Anderson Building, Glasgow. G4 0NG
> _______________________________________________
> gpfsug-discuss mailing list
> gpfsug-discuss at spectrumscale.org
> http://gpfsug.org/mailman/listinfo/gpfsug-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20180122/4e09ddf0/attachment-0002.htm>