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 _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
