[Lustre-discuss] Future of lustre 1.8.3+
Andreas Dilger
andreas.dilger at oracle.com
Wed May 26 08:18:47 PDT 2010
The problem with SELinux is that it is trying to access the security
xattr for each file access but Lustre does not cache xattrs on the
client.
The other main question about SELinux is whether it even makes sense
in a distributed environment.
For now (see bug) we have just disabled the access to this specific
attribute in Lustre. It would be nice if someone with more
understanding of SELinux would investigate if there is some global
settings file that could be modified to exclude Lustre from the
security policy checking, and then we can push this to the upstream
distros.
Cheers, Andreas
On 2010-05-26, at 8:43, Gregory Matthews <greg.matthews at diamond.ac.uk>
wrote:
> Guy Coates wrote:
>> One thing to watch out for in your kernel configs is to make sure
>> that:
>>
>> CONFIG_SECURITY_FILE_CAPABILITIES=N
>
> I hope this is not the case for the now obsolete:
>
> CONFIG_EXT3_FS_SECURITY=y
>
> which appears to be enabled by default on RHEL5.x
>
> Its not entirely clear to me what this is for but would metadata
> performance be better without it?
>
> GREG
>
>>
>> otherwise you will run into:
>>
>> https://bugzilla.lustre.org/show_bug.cgi?id=21439
>>
>> (each write call causes 2 getxattr calls, which will pound your MDS
>> into
>> the ground).
>>
>> The SLES11, debian/lenny and ubuntu kernels all have this feature
>> set,
>> so if you are building clients against those kernels, you may be in
>> trouble.
>>
>>
>> Cheers,
>>
>> Guy
>>
>
>
> --
> Greg Matthews 01235 778658
> Senior Computer Systems Administrator
> Diamond Light Source, Oxfordshire, UK
> _______________________________________________
> Lustre-discuss mailing list
> Lustre-discuss at lists.lustre.org
> http://lists.lustre.org/mailman/listinfo/lustre-discuss
More information about the lustre-discuss
mailing list