<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small">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.<br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><img src="https://docs.google.com/uc?export=download&id=1qBobw7lgHUL5kvclOrp0EeujITqmX4ZE&revid=0B2nrOyWM3zSNeVA3M1VXN1U2bzJncmxQSVV0cDFiOGUyYXVRPQ"><br></div></div></div></div></div>
<br><div class="gmail_quote">2018-01-22 4:57 GMT-05:00 Jonathan Buzzard <span dir="ltr"><<a href="mailto:jonathan.buzzard@strath.ac.uk" target="_blank">jonathan.buzzard@strath.ac.uk</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 22/01/18 03:41, Stephen Ulmer wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Harold,<br>
<br>
The way I read your question, no one has actually answered it fully:<br>
<br>
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.<br>
<br>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
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?<br>
<br>
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.<br>
<br>
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 ħ.<span class=""><br>
<br>
<br>
JAB.<br>
<br>
-- <br>
Jonathan A. Buzzard                         Tel: <a href="tel:%2B44141-5483420" value="+441415483420" target="_blank">+44141-5483420</a><br>
HPC System Administrator, ARCHIE-WeSt.<br>
University of Strathclyde, John Anderson Building, Glasgow. G4 0NG<br></span><span class="">
______________________________<wbr>_________________<br>
gpfsug-discuss mailing list<br>
gpfsug-discuss at <a href="http://spectrumscale.org" rel="noreferrer" target="_blank">spectrumscale.org</a><br>
</span><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" rel="noreferrer" target="_blank">http://gpfsug.org/mailman/list<wbr>info/gpfsug-discuss</a><br>
</blockquote></div><br></div>