[Lustre-discuss] Future of lustre 1.8.3+

[Andreas Dilger]

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