<html><body><p>Hi,<br><br>in all cases a recall request will be handled transparent for the user at the time a migrated files is accessed. This can't be prevented and has two down sides: a) the space used in the file system increases and b) random access to storage media in the Spectrum Protect server happens. With newer versions of Spectrum Protect for Space Management a so called tape optimized recall method is available that can reduce the impact to the system (especially Spectrum Protect server).<br>If the problem was that the file system went out of space at the time the recalls came in I would recommend to reduce the threshold settings for the file system and increase the number of premigrated files. This will allow to free space very quickly if needed. If you didn't use the policy based threshold migration so far I recommend to use it. This method is significant faster compared to the classical HSM based threshold migration approach. <br><br>Greetings, Dominic.<br><br>______________________________________________________________________________________________________________<br>Dominic Mueller-Wicke | IBM Spectrum Protect Development | Technical Lead | +49 7034 64 32794 | dominic.mueller@de.ibm.com<br><br>Vorsitzende des Aufsichtsrats: Martina Koederitz; Geschäftsführung: Dirk Wittkopp<br>Sitz der Gesellschaft: Böblingen; Registergericht: Amtsgericht Stuttgart, HRB 243294<br><font size="2" color="#800080">----- Forwarded by Dominic Mueller-Wicke01/Germany/IBM</font><font size="2" color="#800080"> on 08.03.2016 18:21</font><font size="2" color="#800080"> -----</font><br><br><font size="2" color="#5F5F5F">From: </font><font size="2">Jaime Pinto <pinto@scinet.utoronto.ca></font><br><font size="2" color="#5F5F5F">To: </font><font size="2">gpfsug main discussion list <gpfsug-discuss@spectrumscale.org></font><br><font size="2" color="#5F5F5F">Date: </font><font size="2">08.03.2016 17:36</font><br><font size="2" color="#5F5F5F">Subject: </font><font size="2">[gpfsug-discuss] GPFS+TSM+HSM: staging vs. migration priority</font><br><font size="2" color="#5F5F5F">Sent by: </font><font size="2">gpfsug-discuss-bounces@spectrumscale.org</font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br><br><tt>I'm wondering whether the new version of the "Spectrum Suite" will <br>allow us set the priority of the HSM migration to be higher than <br>staging.<br><br><br>I ask this because back in 2011 when we were still using Tivoli HSM <br>with GPFS, during mixed requests for migration and staging operations, <br>we had a very annoying behavior in which the staging would always take <br>precedence over migration. The end-result was that the GPFS would fill <br>up to 100% and induce a deadlock on the cluster, unless we identified <br>all the user driven stage requests in time, and killed them all. We <br>contacted IBM support a few times asking for a way fix this, and were <br>told it was built into TSM. Back then we gave up IBM's HSM primarily <br>for this reason, although performance was also a consideration (more <br>to this on another post).<br><br>We are now reconsidering HSM for a new deployment, however only if <br>this issue has been resolved (among a few others).<br><br>What has been some of the experience out there?<br><br>Thanks<br>Jaime<br><br><br><br><br>---<br>Jaime Pinto<br>SciNet HPC Consortium - Compute/Calcul Canada<br></tt><tt>www.scinet.utoronto.ca</tt><tt> - </tt><tt>www.computecanada.org</tt><tt><br>University of Toronto<br>256 McCaul Street, Room 235<br>Toronto, ON, M5T1W5<br>P: 416-978-2755<br>C: 416-505-1477<br><br>----------------------------------------------------------------<br>This message was sent using IMP at SciNet Consortium, University of Toronto.<br><br><br>_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at spectrumscale.org<br></tt><tt><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a></tt><tt><br><br></tt><br><br><BR>
</body></html>