<font size=2 face="sans-serif">If your restore software uses the gpfs_fputattrs()
or gpfs_fputattrswithpathname methods, notice there are some options to
control the pool.  </font><br><br><font size=2 face="sans-serif">AND there is also the possibility of
using the little known "RESTORE" policy rule to algorithmically
control the pool selection by different criteria than</font><br><font size=2 face="sans-serif">the SET POOL rule.  When all else
fails ... Read The Fine Manual ;-)<br></font><br><br><br><br><br><font size=1 color=#5f5f5f face="sans-serif">From:      
 </font><font size=1 face="sans-serif">"Buterbaugh, Kevin
L" <Kevin.Buterbaugh@Vanderbilt.Edu></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">06/07/2018 03:37 PM</font><br><font size=1 color=#5f5f5f face="sans-serif">Subject:    
   </font><font size=1 face="sans-serif">Re: [gpfsug-discuss]
Capacity pool filling</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>Hi Uwe,<br><br>Thanks for your response.<br><br>So our restore software lays down the metadata first, then the data.  While
it has no specific knowledge of the extended attributes, it does back them
up and restore them.  So the only explanation that makes sense to
me is that since the inode for the file says that the file should be in
the gpfs23capacity pool, the data gets written there.<br><br>Right now I don’t have time to do an analysis of the “live” version
of a fileset and the “restored” version of that same fileset to see if
the placement of the files matches up.  My quick and dirty checks
seem to show files getting written to all 3 pools.  Unfortunately,
we have no way to tell our tape software to ignore files from the gpfs23capacity
pool (and we’re aware that we won’t need those files).  We’ve also
determined that it is actually quicker to tell our tape system to restore
all files from a fileset than to take the time to tell it to selectively
restore only certain files … and the same amount of tape would have to
be read in either case.<br><br>Our SysAdmin who is primary on tape backup and restore was going on vacation
the latter part of the week, so he decided to be helpful and just queue
up all the restores to run one right after the other.  We didn’t
realize that, so we are solving our disk space issues by slowing down the
restores until we can run more instances of the script that replaces the
corrupted files and deletes the unneeded restored files.<br><br>Thanks again…<br><br>Kevin<br><br>> On Jun 7, 2018, at 1:34 PM, Uwe Falke <UWEFALKE@de.ibm.com>
wrote:<br>> <br>>> However, I took a look in one of the restore directories under
<br>>> /gpfs23/ RESTORE using mmlsattr and I see files in all 3 pools!
<br>> <br>> <br>>> So ? I don?t think GPFS is doing this but the next thing I am
<br>>> going to do is follow up with our tape software vendor ? I bet
<br>>> they preserve the pool attribute on files and - like Jaime said
- <br>>> old stuff is therefore hitting the gpfs23capacity pool.<br>> <br>> Hm, then the backup/restore must be doing very funny things. Usually,
GPFS <br>> should rule the <br>> placement of new files, and I assume that a restore of a file, in
<br>> particular under a different name, <br>> creates a new file. So, if your backup tool does override that GPFS
<br>> placement, it must be very <br>> intimate with Scale :-). <br>> I'd do some list scans of the capacity pool just to see what the files
<br>> appearing there from tape have in common. <br>> If it's really that these files' data were on the capacity pool at
the <br>> last backup, they should not be affected by your dead NSD and a restore
is <br>> in vain anyway.<br>> <br>> If that doesn't help or give no clue, then, if the data pool has some
more <br>> free  space, you might try to run an upward/backward migration
from <br>> capacity to data . <br>> <br>> And, yeah, as GPFS tends to stripe over all NSDs, all files in data
large <br>> enough plus some smaller ones would have data on your broken NSD.
That's <br>> the drawback of parallelization.<br>> Maybe you'd ask the storage vendor whether they supply some more storage
<br>> for the fault of their (redundant?) device to alleviate your current
<br>> storage shortage ?<br>> <br>> Mit freundlichen Grüßen / Kind regards<br>> <br>> <br>> Dr. Uwe Falke<br>> <br>> IT Specialist<br>> High Performance Computing Services / Integrated Technology Services
/ <br>> Data Center Services<br>> -------------------------------------------------------------------------------------------------------------------------------------------<br>> IBM Deutschland<br>> Rathausstr. 7<br>> 09111 Chemnitz<br>> Phone: +49 371 6978 2165<br>> Mobile: +49 175 575 2877<br>> E-Mail: uwefalke@de.ibm.com<br>> -------------------------------------------------------------------------------------------------------------------------------------------<br>> IBM Deutschland Business & Technology Services GmbH / Geschäftsführung:
<br>> Thomas Wolter, Sven Schooß<br>> Sitz der Gesellschaft: Ehningen / Registergericht: Amtsgericht Stuttgart,
<br>> HRB 17122 <br>> <br>> <br>> _______________________________________________<br>> gpfsug-discuss mailing list<br>> gpfsug-discuss at spectrumscale.org<br>> </font></tt><a href="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgpfsug.org%2Fmailman%2Flistinfo%2Fgpfsug-discuss&data=02%7C01%7CKevin.Buterbaugh%40vanderbilt.edu%7Cacad30699025407bc67b08d5cca54bca%7Cba5a7f39e3be4ab3b45067fa80faecad%7C0%7C1%7C636639932669887596&sdata=vywTFbG4O0lquAIAVfa0csdC0HtpvfhY8%2FOjqm98fxI%3D&reserved=0"><tt><font size=2>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgpfsug.org%2Fmailman%2Flistinfo%2Fgpfsug-discuss&data=02%7C01%7CKevin.Buterbaugh%40vanderbilt.edu%7Cacad30699025407bc67b08d5cca54bca%7Cba5a7f39e3be4ab3b45067fa80faecad%7C0%7C1%7C636639932669887596&sdata=vywTFbG4O0lquAIAVfa0csdC0HtpvfhY8%2FOjqm98fxI%3D&reserved=0</font></tt></a><tt><font size=2><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><br></font></tt><br><br><BR>