Re: [lustre-discuss] State of the upstream client

[Dilger, Andreas]

On May 23, 2017, at 11:15, E.S. Rosenberg  wrote:
> 
> Hi all,
> So I may be asking for something that will anyhow be dealt with at LUG 2017 
> but I actually would like to know.
> 
> At LUG 2016 there was a talk that sounded very hopeful that the upstream 
> version of lustre was taking leaps and bounds to being in sync with the main 
> Lustre project.
> 
> Where are we now on this?
> 
> We switched away from upstream due to its' instabilities and incompatibility 
> with Lustre 2.8.0 servers but will soon be building new kernels, obviously 
> we'll be testing either way but I do need to decide whether its' even worth 
> testing.

James Simmons is the expert here, but AFAIK the upstream client is updated to 
2.8.5x or so, which means it is getting a lot of the bugfixes from master, and 
also the features.  So, I'd say it is likely worthwhile to look at again, if 
2.8.0 support was preventing you from trying it before.

Cheers, Andreas
--
Andreas Dilger
Lustre Principal Architect
Intel Corporation







___
lustre-discuss mailing list
lustre-discuss@lists.lustre.org
http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org

Re: [lustre-discuss] seclabel

[Dilger, Andreas]

On May 19, 2017, at 08:47, Robin Humble  wrote:
> 
> Hi Sebastien,
> 
> On Wed, May 17, 2017 at 02:37:31PM +, Sebastien Buisson wrote:
>> Le 17 mai 2017 à 16:16, Robin Humble  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?

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.

> 
>> In any case, it is important to make clear that file capabilities, the 
>> feature you want to use, is completely distinct from SELinux.
>> On the one hand, Capabilities are a Linux mechanism to refine permissions 
>> granted to privileged processes, by dividing the privileges traditionally 
>> associated with superuser into distinct units (known as capabilities).
>> On the other hand, SELinux is the Linux implementation of Mandatory Access 
>> Control.
>> Both Capabilities and SELinux rely on values stored into file extended 
>> attributes, but this is the only thing they have in common.
> 
> 10-4. thanks.
> 
> 'ls --color' requests the security.capability xattr so this would
> be heavily accessed. do you think this is handled well enough currently
> to not affect performance significantly?

Good old "ls --color".  The support for statx() _just_ got into the kernel 
after 10 years
of trying, so that in another 5 years once "ls" is updated and in distros, then 
"ls --color"
will not do an extra RPC for each file to get the file permission to color a 
file differently
based on the executable status.

I guess if this xattr is cached from open time (or negative cached if missing), 
then this
wouldn't add significant overhead for a local getxattr call.  It should be 
possible to turn
on RPC tracing with "lctl set_param debug=+rpctrace" and count the RPCs for 
some operations
with the patch applied and removed, and see what the differences are.

Cheers, Andreas
--
Andreas Dilger
Lustre Principal Architect
Intel Corporation







___
lustre-discuss mailing list
lustre-discuss@lists.lustre.org
http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org

[lustre-discuss] State of the upstream client

[E.S. Rosenberg]

Hi all,
So I may be asking for something that will anyhow be dealt with at LUG 2017
but I actually would like to know.

At LUG 2016 there was a talk that sounded very hopeful that the upstream
version of lustre was taking leaps and bounds to being in sync with the
main Lustre project.

Where are we now on this?

We switched away from upstream due to its' instabilities and
incompatibility with Lustre 2.8.0 servers but will soon be building new
kernels, obviously we'll be testing either way but I do need to decide
whether its' even worth testing.

Thanks,
Eli
___
lustre-discuss mailing list
lustre-discuss@lists.lustre.org
http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org