<tt><font size=2>>- Quota management on the home cluster - we need
a way of ensuring<br>>people don't write data to the cache which can't be accomodated on<br>>home. Probably not insurmountable but needs a bit of thought...<br></font></tt><br><tt><font size=2>You could set same quotas between cache and home clusters.
AFM does not support replication of filesystem metadata like quotas, fileset
configuration etc...</font></tt><br><tt><font size=2><br>>- It seems inodes on the cache only get freed when they are deleted
on<br>>the cache cluster - not if they get deleted from the home cluster or<br>>when the blocks are evicted from the cache. Does this become an issue<br>>in time?</font></tt><br><br><font size=2 face="sans-serif">AFM periodically revalidates with home
cluster. If the files/dirs were already deleted at home cluster, AFM moves
them to <fileset path>/.ptrash directory at cache cluster during
the revalidation. These files can be removed manually by user or auto eviction
process. If the .ptrash directory is not cleaned up on time, it might result
into quota issues at cache cluster.</font><br><br><font size=2 face="sans-serif">~Venkat (vpuvvada@in.ibm.com)</font><br><br><br><br><font size=1 color=#5f5f5f face="sans-serif">From:      
 </font><font size=1 face="sans-serif">Robert Horton <robert.horton@icr.ac.uk></font><br><font size=1 color=#5f5f5f face="sans-serif">To:      
 </font><font size=1 face="sans-serif">"gpfsug-discuss@spectrumscale.org"
<gpfsug-discuss@spectrumscale.org></font><br><font size=1 color=#5f5f5f face="sans-serif">Date:      
 </font><font size=1 face="sans-serif">11/23/2020 08:51 PM</font><br><font size=1 color=#5f5f5f face="sans-serif">Subject:    
   </font><font size=1 face="sans-serif">[EXTERNAL] [gpfsug-discuss]
AFM experiences?</font><br><font size=1 color=#5f5f5f face="sans-serif">Sent by:    
   </font><font size=1 face="sans-serif">gpfsug-discuss-bounces@spectrumscale.org</font><br><hr noshade><br><br><br><tt><font size=2>Hi all,<br><br>We're thinking about deploying AFM and would be interested in hearing<br>from anyone who has used it in anger - particularly independent writer.<br><br>Our scenario is we have a relatively large but slow (mainly because it<br>is stretched over two sites with a 10G link) cluster for long/medium-<br>term storage and a smaller but faster cluster for scratch storage in<br>our HPC system. What we're thinking of doing is using some/all of the<br>scratch capacity as an IW cache of some/all of the main cluster, the<br>idea to reduce the need for people to manually move data between the<br>two.<br><br>It seems to generally work as expected in a small test environment,<br>although we have a few concerns:<br><br>- Quota management on the home cluster - we need a way of ensuring<br>people don't write data to the cache which can't be accomodated on<br>home. Probably not insurmountable but needs a bit of thought...<br><br>- It seems inodes on the cache only get freed when they are deleted on<br>the cache cluster - not if they get deleted from the home cluster or<br>when the blocks are evicted from the cache. Does this become an issue<br>in time?<br><br>If anyone has done anything similar I'd be interested to hear how you<br>got on. It would be intresting to know if you created a cache fileset<br>for each home fileset or just one for the whole lot, as well as any<br>other pearls of wisdom you may have to offer.<br><br>Thanks!<br>Rob<br><br>-- <br>Robert Horton | Research Data Storage Lead<br>The Institute of Cancer Research | 237 Fulham Road | London | SW3 6JB<br>T +44 (0)20 7153 5350 | E robert.horton@icr.ac.uk | W </font></tt><a href="www.icr.ac.uk"><tt><font size=2>www.icr.ac.uk</font></tt></a><tt><font size=2>|<br>Twitter @ICR_London<br>Facebook: </font></tt><a href="www.facebook.com/theinstituteofcancerresearch"><tt><font size=2>www.facebook.com/theinstituteofcancerresearch</font></tt></a><tt><font size=2><br><br>The Institute of Cancer Research: Royal Cancer Hospital, a charitable Company
Limited by Guarantee, Registered in England under Company No. 534147 with
its Registered Office at 123 Old Brompton Road, London SW7 3RP.<br><br>This e-mail message is confidential and for use by the addressee only.
 If the message is received by anyone other than the addressee, please
return the message to the sender by replying to it and then delete the
message from your computer and network.<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><br></font></tt><br><br><BR>