<html><body><p><font size="2">Also, be aware there have been massive improvements in AFM, in terms of usability, reliablity and performance. </font><br><br><font size="2">I just completed a project where we moved about 3/4 PB during 7x24 operations to retire a very old storage system (1st Gen IBM GSS) to a new ESS. We were able to get considerable performance but not without effort, it allowed the client to continue operations and migrate to new hardware seamlessly.</font><br><br><font size="2">The new v5.1 AFM feature supports filesystem level AFM which would have greatly simplified the effort and I believe will make AFM vastly easier to implement in the general case. </font><br><br><font size="2">I'll leave it to Venkat and others on the development team to share more details about improvements. </font><br><br><br><font size="2" face="Arial">Steven A. Daniels</font><br><font size="2" face="Arial">Cross-brand Client Architect</font><br><font size="2" face="Arial">Senior Certified IT Specialist</font><br><font size="2" face="Arial">National Programs</font><br><font size="2" face="Arial">Fax and Voice: 3038101229</font><br><a href="mailto:sadaniel@us.ibm.com"><u><font size="2" color="#0000FF" face="Arial">sadaniel@us.ibm.com</font></u></a><br><a href="http://www.ibm.com/"><u><font size="2" color="#0000FF" face="Arial">http://www.ibm.com</font></u></a><br><img src="cid:1__=8FBB0C06DFCB88608f9e8a93df938690918c8FB@" width="120" height="84"><br><br><img width="16" height="16" src="cid:2__=8FBB0C06DFCB88608f9e8a93df938690918c8FB@" border="0" alt="Inactive hide details for Stephen Ulmer ---03/11/2021 06:47:59 AM---Thank you! Would you mind letting me know in what era you m"><font size="2" color="#424282">Stephen Ulmer ---03/11/2021 06:47:59 AM---Thank you! Would you mind letting me know in what era you made your evaluation? I’m not suggesting y</font><br><br><font size="2" color="#5F5F5F">From: </font><font size="2">Stephen Ulmer <ulmer@ulmer.org></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">Cc: </font><font size="2">bill.burke.860@gmail.com</font><br><font size="2" color="#5F5F5F">Date: </font><font size="2">03/11/2021 06:47 AM</font><br><font size="2" color="#5F5F5F">Subject: </font><font size="2">[EXTERNAL] Re: [gpfsug-discuss] Fwd: FW: Backing up GPFS with Rsync</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>Thank you! Would you mind letting me know in what era you made your evaluation?<br><br>I’m not suggesting you should change anything at all, but when I make recommendations for my own customers I like to be able to associate the level of GPFS with the anecdotes. I view the software as more of a stream of features and capabilities than as a set product.<br><br>Different clients have different requirements, so every implementation could be different. When I add someone else’s judgement to my own, I just like getting as close to their actual evaluation scenario as possible.<br><br>Your original post was very thoughtful, and I appreciate your time.<br><br> -- <br>Stephen<br><br>
<ul><ul>On Mar 11, 2021, at 7:58 AM, Tagliavini, Enrico <enrico.tagliavini@fmi.ch> wrote:<br><br> <br>Hello Stephen,<br><br>actually not a dumb question at all. We evaluated AFM quite a bit before turning it down.<br><br>The horror stories about it and massive data loss are too scary. Plus we had actual reports of very bad performance. Personally I think AFM is very complicated, overcomplicated for what we need. We need the data safe, we don't need active / active DR or anything like that. While AFM can technically do what we need the complexity of its design makes it too easy to make a mistake and cause a service disruption or, even worst, data loss. We are a very small institute with a small IT team, so investing time in making it right was also not really worth it due to the high TCO.<br><br>Kind regards.<br><br><tt>-- </tt><br><tt>Enrico Tagliavini<br>Systems / Software Engineer<br><br>enrico.tagliavini@fmi.ch<br><br>Friedrich Miescher Institute for Biomedical Research<br>Infomatics<br><br>Maulbeerstrasse 66<br>4058 Basel<br>Switzerland<br><br><br><br></tt><br><br>On Thu, 2021-03-11 at 08:17 -0500, Stephen Ulmer wrote:
<ul>I’m going to ask what may be a dumb question:<br><br>Given that you have GPFS on both ends, what made you decide to NOT use AFM?<br><br> -- <br>Stephen<br><br><br>On Mar 11, 2021, at 3:56 AM, Tagliavini, Enrico <enrico.tagliavini@fmi.ch> wrote:<br><br>Hello William,<br><br>I've got your email forwarded my another user and I decided to subscribe to give you my two cents.<br><br>I would like to warn you about the risk of dong what you have in mind. Using the GPFS policy engine to get a list of file to rsync is<br>easily going to get you with missing data in the backup. The problem is that there are cases that are not covered by it. For example<br>if you mv a folder with a lot of nested subfolders and files none of the subfolders would show up in your list of files to be updated.<br><br>DM API would be the way to go, as you could replicate the mv on the backup side, but you must not miss any event, which scares me<br>enough not to go that route.<br><br>What I ended up doing instead: we run GPFS on both side, main and backup storage. So I use the policy engine on both sides and just<br>build up the differences. We have about 250 million files and this is surprisingly fast. On top of that add all the files for which<br>the ctime changes in the last couple of days (to update metadata info).<br><br>Good luck.<br>Kind regards.<br><br>-- <br><br>Enrico Tagliavini<br>Systems / Software Engineer<br><br>enrico.tagliavini@fmi.ch<br><br>Friedrich Miescher Institute for Biomedical Research<br>Infomatics<br><br>Maulbeerstrasse 66<br>4058 Basel<br>Switzerland<br><br><br><br><br>-------- Forwarded Message --------
<ul><br>-----Original Message-----<br>From: gpfsug-discuss-bounces@spectrumscale.org <gpfsug-discuss-bounces@spectrumscale.org> On Behalf Of Ryan Novosielski<br>Sent: Wednesday, March 10, 2021 3:22 AM<br>To: gpfsug main discussion list <gpfsug-discuss@spectrumscale.org><br>Subject: Re: [gpfsug-discuss] Backing up GPFS with Rsync<br><br>Yup, you want to use the policy engine:<br><br><a href="https://www.ibm.com/support/knowledgecenter/STXKQY_4.2.0/com.ibm.spectrum.scale.v4r2.adv.doc/bl1adv_policyrules.htm">https://www.ibm.com/support/knowledgecenter/STXKQY_4.2.0/com.ibm.spectrum.scale.v4r2.adv.doc/bl1adv_policyrules.htm</a><br><br>Something in here ought to help. We do something like this (but I’m reluctant to provide examples as I’m actually suspicious that we<br>don’t have it quite right and are passing far too much stuff to rsync).<br><br>--<br>#BlackLivesMatter<br>____
<ul>\\UTGERS, |---------------------------*O*---------------------------<br>_// the State | Ryan Novosielski - novosirj@rutgers.edu<br>\\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS Campus<br> \\ of NJ | Office of Advanced Research Computing - MSB C630, Newark</ul> `'<br><br>On Mar 9, 2021, at 9:19 PM, William Burke <bill.burke.860@gmail.com> wrote:<br><br> I would like to know what files were modified/created/deleted (only for the current day) on the GPFS's file system so that I<br>could rsync ONLY those files to a predetermined external location. I am running GPFS 4.2.3.9<br><br>Is there a way to access the GPFS's metadata directly so that I do not have to traverse the filesystem looking for these files? If<br>i use the rsync tool it will scan the file system which is 400+ million files. Obviously this will be problematic to complete a<br>scan in a day, if it would ever complete single-threaded. There are tools or scripts that run multithreaded rsync but it's still a<br>brute force attempt. and it would be nice to know where the delta of files that have changed.<br><br>I began looking at Spectrum Scale Data Management (DM) API but I am not sure if this is the best approach to looking at the GPFS<br>metadata - inodes, modify times, creation times, etc.<br><br><br><br>--<br><br>Best Regards,<br><br>William Burke (he/him)<br>Lead HPC Engineer<br>Advance Research Computing<br>860.255.8832 m | LinkedIn<br>_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at spectrumscale.org<br><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss&d=DwQFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=6mf8yZ-lDnfsy3mVONFq1RV1ypXT67SthQnq3D6Ym4Q&m=hSVvvIGpqQhKt_u_TKHdjoXyU-z7P14pCBQ5pA7MMFA&s=g2hkl0Raj7QbLvqRZfDk6nska0crl4Peh4kd8YwiO6k&e="><u><font color="#0000FF">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</font></u></a><br><br>_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at spectrumscale.org<br><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss&d=DwQFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=6mf8yZ-lDnfsy3mVONFq1RV1ypXT67SthQnq3D6Ym4Q&m=hSVvvIGpqQhKt_u_TKHdjoXyU-z7P14pCBQ5pA7MMFA&s=g2hkl0Raj7QbLvqRZfDk6nska0crl4Peh4kd8YwiO6k&e="><u><font color="#0000FF">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</font></u></a></ul>_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at spectrumscale.org<u><font color="#0000FF"><br></font></u><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss&d=DwQFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=6mf8yZ-lDnfsy3mVONFq1RV1ypXT67SthQnq3D6Ym4Q&m=hSVvvIGpqQhKt_u_TKHdjoXyU-z7P14pCBQ5pA7MMFA&s=g2hkl0Raj7QbLvqRZfDk6nska0crl4Peh4kd8YwiO6k&e="><u><font color="#0000FF">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</font></u></a><br>_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at spectrumscale.org<br><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=6mf8yZ-lDnfsy3mVONFq1RV1ypXT67SthQnq3D6Ym4Q&m=hSVvvIGpqQhKt_u_TKHdjoXyU-z7P14pCBQ5pA7MMFA&s=g2hkl0Raj7QbLvqRZfDk6nska0crl4Peh4kd8YwiO6k&e="><u><font color="#0000FF">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</font></u></a></ul>_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at spectrumscale.org<u><font color="#0000FF"><br></font></u><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss&d=DwQFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=6mf8yZ-lDnfsy3mVONFq1RV1ypXT67SthQnq3D6Ym4Q&m=hSVvvIGpqQhKt_u_TKHdjoXyU-z7P14pCBQ5pA7MMFA&s=g2hkl0Raj7QbLvqRZfDk6nska0crl4Peh4kd8YwiO6k&e="><u><font color="#0000FF">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</font></u></a><tt><font size="2">_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at spectrumscale.org<br></font></tt><tt><font size="2"><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=6mf8yZ-lDnfsy3mVONFq1RV1ypXT67SthQnq3D6Ym4Q&m=hSVvvIGpqQhKt_u_TKHdjoXyU-z7P14pCBQ5pA7MMFA&s=g2hkl0Raj7QbLvqRZfDk6nska0crl4Peh4kd8YwiO6k&e=">https://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=6mf8yZ-lDnfsy3mVONFq1RV1ypXT67SthQnq3D6Ym4Q&m=hSVvvIGpqQhKt_u_TKHdjoXyU-z7P14pCBQ5pA7MMFA&s=g2hkl0Raj7QbLvqRZfDk6nska0crl4Peh4kd8YwiO6k&e=</a></font></tt><tt><font size="2"> <br></font></tt><br><br></ul></ul><BR>
</body></html>