[Lustre-discuss] Questions about Lustre ACLs

Yong Fan Yong.Fan at Sun.COM
Fri Jul 25 21:44:19 PDT 2008


Kilian CAVALOTTI 写道:
> Hi all,
>
> I've got a couple questions about ACLs in Lustre:
>
>
> 1. When they're enabled on the MDS, can a client mount the filesystem 
> without them? It doesn't seem to be the case, but at the same time, the 
> mount.lustre manpage mentions the noacl option in the "client-specific" 
> section.
>   
ACL support is a system range feature. Either all client enable ACL or none.
That means you can not specify which client should enable ACL, but 
others not.
In fact, lustre ACL support depends on MDS, that means MDS mount option 
"acl"/"noacl"
will enable/disable all the luster system ACL support. The client-side 
mount opinion
"acl"/"noacl" are ignored.
> See, for instance:
>
> Checking ACLs on the MDS:
> # lctl get_param -n mdc.home-MDT0000-mdc-*.connect_flags | grep acl
> acl
>
> Mounting the client with no ACLs
> # mount -t lustre -o noacl ibmds2 at o2ib:/home /home
>
> ACLs are still in use:
> # strace ls -al /home/kilian/mpihw.c 2>&1 | grep xattr
> getxattr("/home/kilian/mpihw.c", "system.posix_acl_access"..., 0x0, 0) 
> = -1 ENODATA (No data available)
> getxattr("/home/kilian/mpihw.c", "system.posix_acl_default"..., 0x0, 0) 
> = -1 ENODATA (No data available)
>
> I believe getxattr() should return EOPNOTSUPP instead of ENODATA, if 
> ACLs were disabled.
>   
Yes, you are right. But for your case, it has enable ACL support on 
server-side,
so return -ENODATA is expected.
>
> 2. My second question is about the overhead induced by the ACLs. I 
> didn't do any quantifying measurements, but having ACLs enabled seems 
> to slower all MDS operations. A "ls" in a directory containing a lot of 
> files "feels" way slower when ACLs are enabled on the MDS. Is that 
> something to be expected?
>   
The performance drop for ACL enabled depends on the ACL entry count for 
a file/dir
and operation type.
For empty ACL (NODATA) case (very normal case), there is very little 
overhead.

Thanks!
--
Fan Yong
>
> Thanks,
>   




More information about the lustre-discuss mailing list