<html><body><p>Hi Jamie,<br><br>I see. So, the recall-shutdown would be something for a short time period. right? Just for the time it takes to migrate files out and free space. If HSM would allow the recall-shutdown the impact for the users would be that each access to migrated files would lead to an access denied error. Would that be acceptable for the users?<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><br><img width="16" height="16" src="cid:1__=4EBBF5E2DFA0E9F18f9e8a93df938690918c4EB@" border="0" alt="Inactive hide details for Jaime Pinto ---08.03.2016 21:38:58---Thanks for the suggestions Dominic I remember playing around wit"><font color="#424282">Jaime Pinto ---08.03.2016 21:38:58---Thanks for the suggestions Dominic I remember playing around with premigrated files at the time, and</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">Dominic Mueller-Wicke01/Germany/IBM@IBMDE</font><br><font size="2" color="#5F5F5F">Cc: </font><font size="2">gpfsug-discuss@spectrumscale.org</font><br><font size="2" color="#5F5F5F">Date: </font><font size="2">08.03.2016 21:38</font><br><font size="2" color="#5F5F5F">Subject: </font><font size="2">Re: [gpfsug-discuss] GPFS+TSM+HSM: staging vs. migration priority</font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br><br><tt>Thanks for the suggestions Dominic<br><br>I remember playing around with premigrated files at the time, and that <br>was not satisfactory.<br><br>What we are looking for is a configuration based parameter what will <br>basically break out of the "transparency for the user" mode, and not <br>perform any further recalling, period, if|when the file system <br>occupancy is above a certain threshold (98%). We would not mind if <br>instead gpfs would issue a preemptive "disk full" error message to any <br>user/app/job relying on those files to be recalled, so migration on <br>demand will have a chance to be performance. What we prefer is to swap <br>precedence, ie, any migration requests would be executed ahead of any <br>recalls, at least until a certain amount of free space on the file <br>system has been cleared.<br><br>It's really important that this type of feature is present, for us to <br>reconsider the TSM version of HSM as a solution. It's not clear from <br>the manual that this can be accomplish in some fashion.<br><br>Thanks<br>Jaime<br><br>Quoting Dominic Mueller-Wicke01 <dominic.mueller@de.ibm.com>:<br><br>><br>><br>> Hi,<br>><br>> in all cases a recall request will be handled transparent for the user at<br>> the time a migrated files is accessed. This can't be prevented and has two<br>> down sides: a) the space used in the file system increases and b) random<br>> access to storage media in the Spectrum Protect server happens. With newer<br>> versions of Spectrum Protect for Space Management a so called tape<br>> optimized recall method is available that can reduce the impact to the<br>> system (especially Spectrum Protect server).<br>> If the problem was that the file system went out of space at the time the<br>> recalls came in I would recommend to reduce the threshold settings for the<br>> file system and increase the number of premigrated files. This will allow<br>> to free space very quickly if needed. If you didn't use the policy based<br>> threshold migration so far I recommend to use it. This method is<br>> significant faster compared to the classical HSM based threshold migration<br>> approach.<br>><br>> Greetings, Dominic.<br>><br>> ______________________________________________________________________________________________________________<br>><br>> Dominic Mueller-Wicke | IBM Spectrum Protect Development | Technical Lead |<br>> +49 7034 64 32794 | dominic.mueller@de.ibm.com<br>><br>> Vorsitzende des Aufsichtsrats: Martina Koederitz; Geschäftsführung: Dirk<br>> Wittkopp<br>> Sitz der Gesellschaft: Böblingen; Registergericht: Amtsgericht Stuttgart,<br>> HRB 243294<br>> ----- Forwarded by Dominic Mueller-Wicke01/Germany/IBM on 08.03.2016 18:21<br>> -----<br>><br>> From: Jaime Pinto <pinto@scinet.utoronto.ca><br>> To: gpfsug main discussion list <gpfsug-discuss@spectrumscale.org><br>> Date: 08.03.2016 17:36<br>> Subject: [gpfsug-discuss] GPFS+TSM+HSM: staging vs. migration priority<br>> Sent by: gpfsug-discuss-bounces@spectrumscale.org<br>><br>><br>><br>> 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<br>> 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>><br>><br>><br><br><br><br><br><br><br> ************************************<br> TELL US ABOUT YOUR SUCCESS STORIES<br> </tt><tt><a href="http://www.scinethpc.ca/testimonials">http://www.scinethpc.ca/testimonials</a></tt><tt><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></tt><br><br><BR>
</body></html>