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

[Dave B.]

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

http://www.openafsfoundation.org/help/donate/

Thanks.

********************************
David William Botsch
Programmer/Analyst
@CNFComputing
botsch@cnf.cornell.edu
********************************



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 =
Notes
>>
>> * Support for mainline kernel 4.4 and distribution kernels with
>>       backports from it, alas at a performance penalty (12226 12227 12=
228)
>>       (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 th=
at
> allowed the Linux client to use the splice() family of VFS calls.  Thes=
e
> calls can speed up some transfers (apparently ones involving both a fil=
e
> and a pipe, but I am not a Linux VFS expoert).  However, the API contra=
ct
> 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=
t
> prepared to handle that error (they might be written to expect EINTR, b=
ut
> this is different).  Unfortunately, the original code in OpenAFS 1.6 di=
d
> 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 ver=
y
> noticeable, so we noticed that our usage of the splice() routines was n=
ot
> 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=
th
> 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=
r
> (i.e., money) that is simply not available to OpenAFS right now.  I wis=
h
> 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=
ven
> 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