<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
Hi All,
<div class=""><br class="">
</div>
<div class="">First off, I\u2019m on day 8 of dealing with two different mini-catastrophes at work and am therefore very sleep deprived and possibly missing something obvious \u2026 with that disclaimer out of the way\u2026</div>
<div class=""><br class="">
</div>
<div class="">We have a filesystem with 3 pools: &nbsp;1) system (metadata only), 2) gpfs23data (the default pool if I run mmlspolicy), and 3) gpfs23capacity (where files with an atime - yes atime - of more than 90 days get migrated to by a script that runs out
 of cron each weekend.</div>
<div class=""><br class="">
</div>
<div class="">However \u2026 this morning the free space in the gpfs23capacity pool is dropping \u2026 I\u2019m down to 0.5 TB free in a 582 TB pool \u2026 and I cannot figure out why. &nbsp;The migration script is NOT running \u2026 in fact, it\u2019s currently disabled. &nbsp;So I can only think
 of two possible explanations for this:</div>
<div class=""><br class="">
</div>
<div class="">1. &nbsp;There are one or more files already in the gpfs23capacity pool that someone has started updating. &nbsp;Is there a way to check for that \u2026 i.e. a way to run something like \u201cfind /gpfs23 -mtime -7 -ls\u201d but restricted to only files in the gpfs23capacity
 pool. &nbsp;Marc Kaplan - can mmfind do that?? &nbsp;;-)</div>
<div class=""><br class="">
</div>
<div class="">2. &nbsp;We are doing a large volume of restores right now because one of the mini-catastrophes I\u2019m dealing with is one NSD (gpfs23data pool) down due to a issue with the storage array. &nbsp;We\u2019re working with the vendor to try to resolve that but are
 not optimistic so we have started doing restores in case they come back and tell us it\u2019s not recoverable. &nbsp;We did run \u201cmmfileid\u201d to identify the files that have one or more blocks on the down NSD, but there are so many that what we\u2019re doing is actually restoring
 all the files to an alternate path (easier for out tape system), then replacing the corrupted files, then deleting any restores we don\u2019t need. &nbsp;But shouldn\u2019t all of that be going to the gpfs23data pool? &nbsp;I.e. even if we\u2019re restoring files that are in the gpfs23capacity
 pool shouldn\u2019t the fact that we\u2019re restoring to an alternate path (i.e. not overwriting files with the tape restores) and the default pool is the gpfs23data pool mean that nothing is being restored to the gpfs23capacity pool???</div>
<div class=""><br class="">
</div>
<div class="">Is there a third explanation I\u2019m not thinking of?</div>
<div class=""><br class="">
</div>
<div class="">Thanks...</div>
<br class="">
<div class="">
<div class="">\u2014</div>
<div class="">Kevin Buterbaugh - Senior System Administrator</div>
<div class="">Vanderbilt University - Advanced Computing Center for Research and Education</div>
<div class=""><a href="mailto:Kevin.Buterbaugh@vanderbilt.edu" class="">Kevin.Buterbaugh@vanderbilt.edu</a>&nbsp;- (615)875-9633</div>
<div class=""><br class="">
</div>
<br class="Apple-interchange-newline">
</div>
<br class="">
</body>
</html>