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

Dave B. botsch@cnf.cornell.edu
Mon, 09 May 2016 21:32:27 -0400

As a followon, if you wish to donate money (US tax deductable, I believe)=
towards this or other AFS efforts, developer hour donation levels are now=
live at:



David William Botsch

On May 9, 2016 8:10:16 PM Benjamin Kaduk <kaduk@MIT.EDU> wrote:

> On Mon, 9 May 2016, Rich Sudlow wrote:
>> Thanks for this update - One of the items I see in the 1.6.18 Release =
>> * Support for mainline kernel 4.4 and distribution kernels with
>>       backports from it, alas at a performance penalty (12226 12227 12=
>>       (RT #132677 #132819)
>> I've heard that the performance penalty here is roughly 50% - Is this =
> A bit more background on what happened here: some code went into 1.6 th=
> allowed the Linux client to use the splice() family of VFS calls.  Thes=
> calls can speed up some transfers (apparently ones involving both a fil=
> and a pipe, but I am not a Linux VFS expoert).  However, the API contra=
> 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 no=
> prepared to handle that error (they might be written to expect EINTR, b=
> this is different).  Unfortunately, the original code in OpenAFS 1.6 di=
> not have full error handling for the ERESTARTSYS case, and so was prone=
> reporting "weird" errors back to userspace in rare cases.  A patch in
> upstream Linux 4.4 made the ERESTARTSYS return much more common and ver=
> noticeable, so we noticed that our usage of the splice() routines was n=
> 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, wi=
> 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 manpowe=
> (i.e., money) that is simply not available to OpenAFS right now.  I wis=
> that that was different, but in the absence of more developer hours,
> OpenAFS is going to be prone to stagnation in the future, potentially e=
> to the point of not being able to keep up with changes to the Linux VFS=
> -Ben
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info