[gpfsug-discuss] fast ACL alter solution

[Martin Gasthuber]

Hi Marc,

  your description of the ACL implementation looks like each file has some sort of reference to the ACL - so multiple files could reference the same physical ACL data. In our case, we need to set a large number of files (and directories) to the same ACL (content) - could we take any benefit from these 'pseudo' referencing nature ? i.e. set ACL contents once and the job is done ;-). It looks that mmputacl can only access the ACL data 'through' a filename and not 'directly' - we just need the 'dirty' way ;-)

best regards,
  Martin 
> On 3 Aug, 2015, at 19:05, Marc A Kaplan <makaplan at us.ibm.com> wrote:
> 
> Reality check on GPFS ACLs. 
> 
> I think it would be helpful to understand how ACLs are implemented in GPFS - 
> 
> - All ACLs for a file sytem are stored as records in a special file. 
> - 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. 
> - 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 - 
> it's size is proportional to the number of unique ACLs, not the number of files.   
> 
> And how and what mmapplypolicy can do for you - 
> 
> mmapplypolicy can rapidly scan the directories and inodes of a file system.   
> This scanning bypasses most locking regimes and takes advantage of both parallel processing 
> and streaming full tracks of inodes.  So it is good at finding files (inodes) that satifsy criteria that can 
> be described by an SQL expression over the attributes stored in the inode. 
> 
> BUT to change the attributes of any particular file we must use APIs and code that respect all required locks, 
> log changes, etc, etc. 
> 
> Those changes can be "driven" by the execution phase of mmapplypolicy, in parallel - but overheads are significantly higher per file, 
> than during the scanning  phases of operation. 
> 
> NOW to the problem at hand.  It might be possible to improve ACL updates somewhat by writing a command that processes 
> multiple files at once, still using the same APIs used by the mmputacl command.   
> 
> Hmmm.... it wouldn't be very hard for GPFS development team to modify the mmputacl command to accept a list of files... 
> I see that the Linux command setfacl does accept multiple files in its argument list. 
> 
> Finally and not officially supported nor promised nor especially efficient ....   try getAcl()  as a GPFS SQL policy function._______________________________________________
> gpfsug-discuss mailing list
> gpfsug-discuss at gpfsug.org
> http://gpfsug.org/mailman/listinfo/gpfsug-discuss