<font size=2 face="sans-serif">Hi JAB,</font>
<br>
<br><font size=2 face="sans-serif">many thanks for your answer.</font>
<br>
<br><font size=2 face="sans-serif">Ok, some more background information:</font>
<br>
<br><font size=2 face="sans-serif">We are working with video realtime applications
and uncompressed files. So one project is one folder and some subfolders.
The size of one project could be more than 1TB. That is the reason why
I want to move the whole folder tree.</font>
<br>
<br><font size=2 face="sans-serif">Moving old stuff to the slower storage
is not the problem but moving the files back for working with the realtime
applications. Not every file will be accessed when you open a project.</font>
<br>
<br><font size=2 face="sans-serif">The Clients get access via GPFS-Client
(Windows) and over Samba.</font>
<br>
<br><font size=2 face="sans-serif">Another tool on storage side scan the
files for creating playlists etc. While the migration the playout of the
video files may not dropped.</font>
<br>
<br><font size=2 face="sans-serif">So I think the best way is to find a
solution with mmapplypolicy manually or via crontab.</font>
<br>
<br><font size=2 face="sans-serif">Im must check the access time and the
types of files. If I do not do this never a file will be moved the slower
storage because the special tool always have access to the files.</font>
<br>
<br><font size=2 face="sans-serif">I will try some concepts and give feedback
which solution is working for me.</font>
<br>
<br><font size=2 face="sans-serif">Matthias</font>
<br>
<br>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">Von:
</font><font size=1 face="sans-serif">Jonathan Buzzard <jonathan.buzzard@strath.ac.uk></font>
<br><font size=1 color=#5f5f5f face="sans-serif">An:
</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">Datum:
</font><font size=1 face="sans-serif">01.11.2017 13:18</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Betreff:
</font><font size=1 face="sans-serif">[Newsletter]
Re: [gpfsug-discuss] Combine different rules</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Gesendet von:
</font><font size=1 face="sans-serif">gpfsug-discuss-bounces@spectrumscale.org</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>On Wed, 2017-11-01 at 11:55 +0100, Matthias.Knigge@rohde-schwarz.com<br>
wrote:<br>
> Hi at all, <br>
> <br>
> I configured a tiered storage with two pools. <br>
> <br>
> pool1 >> fast
>> ssd <br>
> pool2 >> slow
>> sata <br>
> <br>
> First I created a fileset and a placement rule to copy the files to<br>
> the fast storage. <br>
> <br>
> After a time of no access the files and folders should be moved to<br>
> the slower storage. This could be done by a migration rule. I want
to<br>
> move the whole project folder to the slower storage. <br>
<br>
Why move the whole project? Just wait if the files are not been<br>
accessed they will get moved in short order. You are really making it<br>
more complicated for no useful or practical gain.<br>
<br>
This is a basic policy to move old stuff from fast to slow disks.<br>
<br>
define(age,(DAYS(CURRENT_TIMESTAMP)-DAYS(ACCESS_TIME)))<br>
define(weighting,<br>
CASE<br>
WHEN age>365<br>
THEN
age*KB_ALLOCATED<br>
WHEN age<30<br>
THEN
0<br>
ELSE<br>
KB_ALLOCATED<br>
END<br>
)<br>
RULE 'ilm' MIGRATE FROM POOL 'fast' THRESHOLD(90,70) WEIGHT(weighting)
TO POOL 'slow'<br>
RULE 'new' SET POOL 'fast' LIMIT(95)<br>
RULE 'spillover' SET POOL 'slow'<br>
<br>
<br>
Basically it says when fast pool is 90% full, flush it down to 70%<br>
full, based on a weighting of the size and age. Basically older bigger<br>
files go first.<br>
<br>
The last two are critical. Allocate new files to the fast pool till it<br>
gets 95% full then start using the slow pool. Basically you have to<br>
stop allocating files to the fast pool long before it gets full<br>
otherwise you will end up with problems. Basically imagine there is<br>
100KB left in the fast pool. I create a file which succeeds because<br>
there is space and start writing. When I get to 100KB the write fails<br>
because there is no space left in the pool, and a file can only be in<br>
one pool at a time. Generally programs will cleanup deleting the failed<br>
write at which point there will be space left and so the cycle goes on.<br>
<br>
<br>
You might want to force some file types onto slower disk. For example<br>
ISO images don't really benefit from ever being on the fast disk.<br>
<br>
/* force ISO images onto nearline storage */<br>
RULE 'iso' SET POOL 'slow' WHERE LOWER(NAME) LIKE '%.iso'<br>
<br>
You also might want to punish people storing inappropriate files on<br>
your server so<br>
<br>
/* force MP3's and the like onto nearline storage forever */<br>
RULE 'mp3' SET POOL 'slow'<br>
WHERE LOWER(NAME) LIKE '%.mp3' OR LOWER(NAME) LIKE
'%.m4a' OR LOWER(NAME) LIKE '%.wma'<br>
<br>
Another rule I used was to migrate files over to a certain size to the<br>
slow pool too.<br>
<br>
> <br>
> If a file in a project folder on the slower storage will be accessed<br>
> this whole folder should be moved back to the faster storage. <br>
> <br>
<br>
Waste of time. In my experience the slow disks when not actually taking<br>
new files from a flush of the fast pools will be doing jack all. That<br>
is under 10 IOPS per second. That's because if you have everything<br>
sized correctly and the right rules people rarely go back to old files.<br>
<br>
As such the penalty for being on the slower disks is most none existent<br>
because there is loads of spare IO capacity on those disks. Secondly by<br>
the time you have spotted the files need moving the chances are your<br>
users have finished with them so moving them gains nothing. Thirdly if<br>
the users start working with those files any change to the file will<br>
result in a new file being written which will automatically go to the<br>
fast disks. It's the standard dance when you save a file; create new<br>
temporary file, write the contents, then do some renaming before<br>
deleting the old one.<br>
<br>
If you are insistent then something like the following would be a<br>
start, but moving a whole project would be a *lot* more complicated. I<br>
disabled the rule because it was a waste of time. I suggest running a<br>
similar rule that prints the files out so you can see how pointless it<br>
is.<br>
<br>
/* migrate recently accessed files back the fast disks */<br>
RULE 'restore' MIGRATE FROM POOL 'slow' WEIGHT(KB_ALLOCATED) TO POOL 'fast'
WHERE age < 1<br>
<br>
Depending on the number of "projects" you anticipate you could
allocate<br>
a project to a fileset and then move whole filesets about but I really<br>
think the idea is one of those that looks sensible at a high level but<br>
in practice is not sensible.<br>
<br>
<br>
> The rules must not run automatically. It is ok when this could
be<br>
> done by a cronjob over night. <br>
> <br>
<br>
I would argue strongly, very strongly that while you might want to<br>
flush the fast pool down every night to a certain amount free, you must<br>
have it set so that should it become full during the day an automatic<br>
flush is triggered. Failure to do so is guaranteed to bite you in the<br>
backside some time down the line.<br>
<br>
<br>
> I am a beginner in writing rules. My idea is to write rules which<br>
> listed files by date and by access and put the output into a file.<br>
> After that a bash script can change the attributes of these files
or<br>
> rather folders. <br>
<br>
Eh, you apply the policy and it does the work!!! More reading required<br>
on the subject I think.<br>
<br>
A bash script would be horribly slow. IBM have put a lot of work into<br>
making the policy engine really really fast. Messing about changing<br>
thousands if not millions of files with a bash script will be much much<br>
slower and is a recipe for disaster.<br>
<br>
Your users will put all sorts of random crap into file and directory<br>
names; backtick's, asterix's, question marks, newlines, UTF-8<br>
characters etc. that will invariably break your bash script unless<br>
carefully escaped. There is no way for you to prevent this. It's the<br>
reason find/xargs have the -print0/-0 options, otherwise stuff will<br>
just mysteriously break on you. It's really better to just sidestep the<br>
whole issue and not process the files with scripts.<br>
<br>
<br>
JAB.<br>
<br>
-- <br>
Jonathan A. Buzzard
Tel: +44141-5483420<br>
HPC System Administrator, ARCHIE-WeSt.<br>
University of Strathclyde, John Anderson Building, Glasgow. G4 0NG<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>
</font></tt>
<br>
<br>