<div dir="ltr"><div>> Disclaimer: I work for one such parallel and fast (and often used for scratch) company called Panasas.</div><div>Ellis, I know Panasas well of course.  You are a great bunch of guys and girls, and have pulled my chestnuts from the fire many times (such as the plaintive call from the customer - we can't access our data. What are all these red lights for - wwe have seen them for weeks. Me - puts in call to 800-PANASAS immediately)<br></div><div>Having been there on my hands and knees installing Panasas systems for UK Government defence customers.</div><div>Installed Panasas in Formula 1 where it had a dramatic effect on our solver times.<br></div><div>Also installing the largest Panasas setup in the world at the UK Rutherford Appleton Laboratory, which is being used for lcimate resarch (JASMIN).</div><div>Been there, seen it, unboxed hundreds of blades.</div><div><br></div><div>>Culling through piles of likely mechanically named files you haven't 
looked at in a long time is difficult as a human exercise, and without 
sufficiently complex media asset management it's also difficult from a 
storage perspective > > as your data may take a /long/ time to even list, 
much less grep through, when pulling from true archive storage.<br></div><div><br></div><div>Excellent point.  In Formula 1 I made a serious study of Architeca Mediaflux for this very purpose (or rather the SGI rebadge)  <a href="http://www.arcitecta.com/Products">http://www.arcitecta.com/Products</a></div><div>We finally did not implement it.</div><div>I recall being asked to put terabytes of wind tunnel data on our system, which consisted of thousands of high resolution frames grabs. In reality no-one was ever going to look at that data again.</div><div><br></div><div>Regarding information lifecycle management, may I go back a long way to data acquisition at CERN. My epxeriment, and in the other experiments of that generation, stored data on round magnetic tapes.</div><div>We knew that there was a limited capacity to keep data long term. So raw data was quickly filtered within the detector. Full readots were kept, but quickly distilled into compact 'Data Summary Tapes'</div><div>For instance, verices would be reconstructed into tracks and the track information kept on the DST. OK, that meant that the full data set coul dnever be re-analyzed in that level of detail, <br></div><div>but the important aspects for the physics are stored long term.</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 12 June 2018 at 15:41, Ellis H. Wilson III <span dir="ltr"><<a href="mailto:ellis@ellisv3.com" target="_blank">ellis@ellisv3.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 06/12/2018 04:06 AM, John Hearns via Beowulf wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In the topic on avoiding fragmentation Chris Samuel wrote:<br>
<br>
 >Our trick in Slurm is to use the slurmdprolog script to set an XFS project<br>
 >quota for that job ID on the per-job directory (created by a plugin which<br>
 >also makes subdirectories there that it maps to /tmp and /var/tmp for the<br>
 >job) on the XFS partition used for local scratch on the node.<br>
<br>
I had never thought of that, and it is a very neat thing to do.<br>
What I would like to discuss is the more general topic of clearing files from 'fast' storage.<br>
Many sites I have seen have dedicated fast/parallel storage which is referred to as scratch space.<br>
The intention is to use this scratch space for the duration of a project, as it is expensive.<br>
However I have often seen that the scratch space i used as permanent storage, contrary to the intentions of whoever sized it, paid for it and installed it.<br>
<br>
I feel that the simplistic 'run a cron job and delete files older than N days' is outdated.<br>
<br>
My personal take is that heirarchical storage is the answere, automatically pushing files to slower and cheaper tiers.<br>
</blockquote>
<br></span>
Disclaimer: I work for one such parallel and fast (and often used for scratch) company called Panasas.<br>
<br>
I disagree with the notion that hierarchical storage is a silver bullet in many HPC-oriented cases.  In fact, I would argue in some environments it poses serious risks to being able to keep a lid on your storage cost and DC footprint, whether that's for scratch, home, or archive storage. People (including myself in my own systems testing) can generate an enormous amount of data that has near-zero value past the project currently being worked on, which may only be measured in weeks or low numbers of months.  In many of my cases it's cheaper to regenerate those many TBs of data then to hold onto it for a year or more.  Auto-tiering scratch data to cheaper storage as it gets colder seems like an easy answer as it takes some of this responsibility away from the users, but you'll still want to /someday/ ditch that data entirely (for scratch-like data that is).  Culling through piles of likely mechanically named files you haven't looked at in a long time is difficult as a human exercise, and without sufficiently complex media asset management it's also difficult from a storage perspective as your data may take a /long/ time to even list, much less grep through, when pulling from true archive storage.<br>
<br>
For true scratch I think the solution presented by many of the posters relating to automatic deletion policies managed by administrators, which develops and forces good data habits, is ultimately the cleanest solution in the long-term.<br>
<br>
Now, tiering within a storage layer based on different types or access frequencies of data is perfectly reasonable and is something we do in our systems.  Also, using external software to automatically tier cold but persistent data (i.e., home dir data) from fast to archive storage is also reasonable.  But there are a lot of pitfalls from trying to automatically tier data that isn't supposed to be (eternally) persistent IMHO.<br>
<br>
Best,<br>
<br>
ellis<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Ellis H. Wilson III, Ph.D.<br>
     <a href="http://www.ellisv3.com" rel="noreferrer" target="_blank">www.ellisv3.com</a></font></span><div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>_________________<br>
Beowulf mailing list, <a href="mailto:Beowulf@beowulf.org" target="_blank">Beowulf@beowulf.org</a> sponsored by Penguin Computing<br>
To change your subscription (digest mode or unsubscribe) visit <a href="http://www.beowulf.org/mailman/listinfo/beowulf" rel="noreferrer" target="_blank">http://www.beowulf.org/mailman<wbr>/listinfo/beowulf</a><br>
</div></div></blockquote></div><br></div>