<font size=2 face="sans-serif">Reality check on GPFS ACLs.</font>
<br>
<br><font size=2 face="sans-serif">I think it would be helpful to understand
how ACLs are implemented in GPFS -</font>
<br>
<br><font size=2 face="sans-serif">- All ACLs for a file sytem are stored
as records in a special file.</font>
<br><font size=2 face="sans-serif">- Each inode that has an ACL (more than
just the classic Posix mode bits) has a non-NULL offset to the governing
ACL in the special acl file.</font>
<br><font size=2 face="sans-serif">- Yes, inodes with identical ACLs will
have the same ACL offset value. Hence in many (most?) use cases, the ACL
file can be relatively small -</font>
<br><font size=2 face="sans-serif">it's size is proportional to the number
of unique ACLs, not the number of files.  </font>
<br>
<br><font size=2 face="sans-serif">And how and what mmapplypolicy can do
for you -</font>
<br>
<br><font size=2 face="sans-serif">mmapplypolicy can rapidly scan the directories
and inodes of a file system.  </font>
<br><font size=2 face="sans-serif">This scanning bypasses most locking
regimes and takes advantage of both parallel processing</font>
<br><font size=2 face="sans-serif">and streaming full tracks of inodes.
 So it is good at finding files (inodes) that satifsy criteria that
can</font>
<br><font size=2 face="sans-serif">be described by an SQL expression over
the attributes stored in the inode.</font>
<br>
<br><font size=2 face="sans-serif">BUT to change the attributes of any
particular file we must use APIs and code that respect all required locks,</font>
<br><font size=2 face="sans-serif">log changes, etc, etc.</font>
<br>
<br><font size=2 face="sans-serif">Those changes can be "driven"
by the execution phase of mmapplypolicy, in parallel - but overheads are
significantly higher per file,</font>
<br><font size=2 face="sans-serif">than during the scanning  phases
of operation.</font>
<br>
<br><font size=2 face="sans-serif">NOW to the problem at hand.  It
might be possible to improve ACL updates somewhat by writing a command
that processes</font>
<br><font size=2 face="sans-serif">multiple files at once, still using
the same APIs used by the mmputacl command.   </font>
<br>
<br><font size=2 face="sans-serif">Hmmm.... it wouldn't be very hard for
GPFS development team to modify the mmputacl command to accept a list of
files...</font>
<br><font size=2 face="sans-serif">I see that the Linux command setfacl
does accept multiple files in its argument list.</font>
<br>
<br><font size=2 face="sans-serif">Finally and not officially supported
nor promised nor especially efficient ....   try getAcl()  as
a GPFS SQL policy function.</font>