[OpenAFS] Re: [OpenAFS-announce] OpenAFS release 1.6.18 available

[Benjamin Kaduk]

On Mon, 9 May 2016, Rich Sudlow wrote:

>
> Thanks for this update - One of the items I see in the 1.6.18 Release Notes
>
> * Support for mainline kernel 4.4 and distribution kernels with
>       backports from it, alas at a performance penalty (12226 12227 12228)
>       (RT #132677 #132819)
>
> I've heard that the performance penalty here is roughly 50% - Is this correct?

A bit more background on what happened here: some code went into 1.6 that
allowed the Linux client to use the splice() family of VFS calls.  These
calls can speed up some transfers (apparently ones involving both a file
and a pipe, but I am not a Linux VFS expoert).  However, the API contract
for these calls permits them to return the ERESTARTSYS error, which
indicates that the caller should reattempt the operation.  Propagating
this error back to userspace is bad, since userland applications are not
prepared to handle that error (they might be written to expect EINTR, but
this is different).  Unfortunately, the original code in OpenAFS 1.6 did
not have full error handling for the ERESTARTSYS case, and so was prone to
reporting "weird" errors back to userspace in rare cases.  A patch in
upstream Linux 4.4 made the ERESTARTSYS return much more common and very
noticeable, so we noticed that our usage of the splice() routines was not
compliant with the API contract for them.  No one stepped forward to
contribute proper error handling, so in order to make the client usable,
we reverted the use of the splice() routines, bringing the performance
back to roughly the 1.4 level.

We would welcome a contribution that reintroduces splice() properly, with
the concomitant performance benefits, but someone or some organization
needs to stump up the development effort.  AuriStor can provide this
functionality because they are putting in a level of developmer manpower
(i.e., money) that is simply not available to OpenAFS right now.  I wish
that that was different, but in the absence of more developer hours,
OpenAFS is going to be prone to stagnation in the future, potentially even
to the point of not being able to keep up with changes to the Linux VFS.

-Ben