<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Perhaps IBM might consider letting you commit it to
<a class="moz-txt-link-freetext" href="https://github.com/gpfsug/gpfsug-tools">https://github.com/gpfsug/gpfsug-tools</a> he says, asking out loud...
It'll require a friendly IBMer to take the reins up for you. Scott?
:-)<br>
<br>
Jez<br>
<br>
<br>
<div class="moz-cite-prefix">On 03/08/17 02:00, Aaron Knister wrote:<br>
</div>
<blockquote type="cite"
cite="mid:e213a08a-32cc-0924-b6d7-1349c6bf272a@nasa.gov">I'm a
little late to the party here but I thought I'd share our recent
experiences.
<br>
<br>
We recently completed a mass UID number migration (half a billion
inodes) and developed two tools ("luke filewalker" and the
"mmilleniumfacl") to get the job done. Both luke filewalker and
the mmilleniumfacl are based heavily on the code in
/usr/lpp/mmfs/samples/util/tsreaddir.c and
/usr/lpp/mmfs/samples/util/tsinode.c.
<br>
<br>
luke filewalker targets traditional POSIX permissions whereas
mmilleniumfacl targets posix ACLs. Both tools traverse the
filesystem in parallel and both but particularly the 2nd, are
extremely I/O intensive on your metadata disks.
<br>
<br>
The gist of luke filewalker is to scan the inode structures using
the gpfs APIs and populate a mapping of inode number to gid and
uid number. It then walks the filesystem in parallel using the
APIs, looks up the inode number in an in-memory hash, and if
appropriate changes ownership using the chown() API.
<br>
<br>
The mmilleniumfacl doesn't have the luxury of scanning for POSIX
ACLs using the GPFS inode API so it walks the filesystem and reads
the ACL of any and every file, updating the ACL entries as
appropriate.
<br>
<br>
I'm going to see if I can share the source code for both tools,
although I don't know if I can post it here since it modified
existing IBM source code. Could someone from IBM chime in here? If
I were to send the code to IBM could they publish it perhaps on
the wiki?
<br>
<br>
-Aaron
<br>
<br>
On 6/30/17 11:20 AM, <a class="moz-txt-link-abbreviated" href="mailto:hpc-luke@uconn.edu">hpc-luke@uconn.edu</a> wrote:
<br>
<blockquote type="cite">Hello,
<br>
<br>
We're trying to change most of our users uids, is there a
clean way to
<br>
migrate all of one users files with say `mmapplypolicy`? We have
to change the
<br>
owner of around 273539588 files, and my estimates for runtime
are around 6 days.
<br>
<br>
What we've been doing is indexing all of the files and
splitting them up by
<br>
owner which takes around an hour, and then we were locking the
user out while we
<br>
chown their files. I made it multi threaded as it weirdly gave a
10% speedup
<br>
despite my expectation that multi threading access from a single
node would not
<br>
give any speedup.
<br>
<br>
Generally I'm looking for advice on how to make the chowning
faster. Would
<br>
spreading the chowning processes over multiple nodes improve
performance? Should
<br>
I not stat the files before running lchown on them, since lchown
checks the file
<br>
before changing it? I saw mention of inodescan(), in an old
gpfsug email, which
<br>
speeds up disk read access, by not guaranteeing that the data is
up to date. We
<br>
have a maintenance day coming up where all users will be locked
out, so the file
<br>
handles(?) from GPFS's perspective will not be able to go stale.
Is there a
<br>
function with similar constraints to inodescan that I can use to
speed up this
<br>
process?
<br>
<br>
Thank you for your time,
<br>
<br>
Luke
<br>
Storrs-HPC
<br>
University of Connecticut
<br>
_______________________________________________
<br>
gpfsug-discuss mailing list
<br>
gpfsug-discuss at spectrumscale.org
<br>
<a class="moz-txt-link-freetext" href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a>
<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<div>
<font face="arial" color="#000000">
<b>Jez Tucker</b><br>
Head of Research and Development, Pixit Media<br>
07764193820 <font color="#FF0000">|</font> <a
href="mailto:jtucker@pixitmedia.com">jtucker@pixitmedia.com</a><br>
<a href="http://www.pixitmedia.com">www.pixitmedia.com</a> <font
color="#FF0000">|</font> <a
href="https://twitter.com/PixitMedia">Tw:@pixitmedia.com</a><br>
</font>
</div>
</div>
</body>
</html>
<br>
<div><a href="http://pixitmedia.com" target="_blank"><img src="http://pixitmedia.com/sig/IBC_emailsig17.png"></a><br><font face="Arial, Helvetica, sans-serif" size="1">This email is confidential in that it is intended for the exclusive attention of the addressee(s) indicated. If you are not the intended recipient, this email should not be read or disclosed to any other person. Please notify the sender immediately and delete this email from your computer system. Any opinions expressed are not necessarily those of the company from which this email was sent and, whilst to the best of our knowledge no viruses or defects exist, no responsibility can be accepted for any loss or damage arising from its receipt or subsequent use of this email.</font></div>