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 <[email protected]> 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 _______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at gpfsug.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
