<div dir="ltr">You would definitely be able to search by inode creation date and find the files you want... our 1.25m file filesystem takes about 47 seconds to query...  One thing I would worry about though is inode deletion and inter-fileset file moves.   The SQL based engine wouldn't be able to identify those changes and so you'd not be able to replicate deletes and such.  <div><br></div><div>Alternatively....</div><div>I have a script that runs in about 4 minutes and it pulls all the data out of the backup indexes, and compares the pre-built hourly file index on our system and identifies files that don't exist in the backup, so I have a daily backup validation...  I filter the file list using ksh's printf date manipulation to filter out files that are less than 2 days old, to reduce the noise.  A modification to this could simply compare a daily file index with the previous day's index, and send rsync a list of files (existing or deleted) based on just a delta of the two indexes (sort|diff), then you could properly account for all the changes.  If you don't care about file modifications just produce both lists based on creation time instead of modification time.  The mmfind command or GPFS policy engine should be able to produce a full file list/index very rapidly.</div><div><br></div><div>In another thread there was a conversation with ACL's...  I don't think our backup system backs up ACL's so I just have GPFS produce a list of all ACL applied objects on the daily, and have a script that just makes a null delimited backup file of every single ACL on our file system... and have a script to apply the ACL's as a "restore".  It's a pretty simple thing to write-up and keeping 90 day history on this lets me compare the ACL evolution on a file very easily.</div><div><br></div><div>Alec</div><div><br></div><div><div>MVH</div><div>Most Victorious Hunting</div><div>(Why should Scandinavians own this cool sign off)</div><div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 9, 2021 at 6:22 PM Ryan Novosielski <<a href="mailto:novosirj@rutgers.edu">novosirj@rutgers.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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" rel="noreferrer" target="_blank">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 don’t have it quite right and are passing far too much stuff to rsync).<br>
<br>
--<br>
#BlackLivesMatter<br>
____<br>
|| \\UTGERS,     |---------------------------*O*---------------------------<br>
||_// the State  |         Ryan Novosielski - <a href="mailto:novosirj@rutgers.edu" target="_blank">novosirj@rutgers.edu</a><br>
|| \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS Campus<br>
||  \\    of NJ  | Office of Advanced Research Computing - MSB C630, Newark<br>
     `'<br>
<br>
> On Mar 9, 2021, at 9:19 PM, William Burke <<a href="mailto:bill.burke.860@gmail.com" target="_blank">bill.burke.860@gmail.com</a>> 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 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 i use the rsync tool it will scan the file system which is 400+ million files.  Obviously this will be problematic to complete a 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 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 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 <a href="http://spectrumscale.org" rel="noreferrer" target="_blank">spectrumscale.org</a><br>
> <a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" rel="noreferrer" target="_blank">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a><br>
<br>
_______________________________________________<br>
gpfsug-discuss mailing list<br>
gpfsug-discuss at <a href="http://spectrumscale.org" rel="noreferrer" target="_blank">spectrumscale.org</a><br>
<a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" rel="noreferrer" target="_blank">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a><br>
</blockquote></div>