[lustre-discuss] seclabel

Robin Humble rjh+lustre at cita.utoronto.ca
Tue Jun 6 07:31:03 PDT 2017

On Tue, May 23, 2017 at 08:08:54PM +0000, Dilger, Andreas wrote:
>On May 19, 2017, at 08:47, Robin Humble <rjh+lustre at cita.utoronto.ca> wrote:
>> On Wed, May 17, 2017 at 02:37:31PM +0000, Sebastien Buisson wrote:
>>> Le 17 mai 2017 à 16:16, Robin Humble <rjh+lustre at cita.utoronto.ca> a écrit :
>>>> I took a gander at the source and noticed that llite/xattr.c
>>>> deliberately filters out 'security.capability' and returns 0/-ENODATA
>>>> for setcap/getcap, which is indeed what strace sees. so setcap/getcap
>>>> is never even sent to the MDS.
>>>> if I remove that filter (see patch on lustre-devel) then setcap/getcap
>>>> works ->
>> ...
>>>> 'b15587' is listed as the reason for the filtering.
>>>> I don't know what that refers to.
>>>> is it still relevant?
>>> b15587 refers to the old Lustre Bugzilla tracking tool:
>>> https://projectlava.xyratex.com/show_bug.cgi?id=15587
>>> Reading the discussion in the ticket, supporting xattr at the time of Lustre 1.8 and 2.0 was causing issues on MDS side in some situations. So it was decided to discard security.capability xattr on Lustre client side. I think Andreas might have some insight, as he apparently participated in b15587.
>> my word that's a long time ago...
>> I don't see much in the way of jira tickets about getxattr issues on
>> MDS in recent times, and they're much more heavily used these days, so
>> I hope that particular problem has long since been fixed.
>> should I open a jira ticket to track re-enabling of security.capabilities?

thanks for everyone's help!

>I don't recall the details of b=15587 off the top of my head, but the high-level issue is
>that the security labels added a significant performance overhead, since they were retrieved
>on every file access, but not cached on the client, even if most systems never used them.
>Seagate implemented the client-side xattr cache for Lustre 2.5, so this should work a lot
>better these days.  I'm not 100% positive if we also cache negative xattr lookups or not,
>so this would need some testing/tracing to see if it generates a large number of RPCs.

fair enough.


More information about the lustre-discuss mailing list