[OpenAFS] low write/read performance with 1.8.x 1.9.0 client

Giovanni Bracco giovanni.bracco@enea.it
Tue, 13 Oct 2020 21:26:43 +0200


Sorry for the typing mistake in  previous mail, but you got the point!

Now with the proper setting at the client startup the result is clear, 
the low performance was indeed due to encryption on!

Thank you, the case is solved but it is indeed impressive that 
encrypting the data transfer reduces performances of a factor 5 !

Giovanni

On 13/10/20 21:11, Benjamin Kaduk wrote:
> Hi Giovanni,
> 
> What you write is generally correct or close to correct, but some details
> differ and I don't know if they are artifacts of your email or reflect your
> actual testing.
> 
> `fs setcrypt -crypt on` and `fs setcrypt -crypt off` are indeed the ways to
> configure the (non-)use of encryption for new connections to the file
> server, but they do only affect new connections and not existing ones.  It
> is easiest for testing to put it in (e.g.) an init script so it runs right
> after cache manager startup, though with care it can still be used later
> on.
> 
> It's fairly easy to tell whether encryption is actually in use by taking a
> packet capture -- wireshark and tcpdump have decoders that should say
> flat-out that a packet is encrypted with rxkad.
> 
> -Ben
> 
> On Tue, Oct 13, 2020 at 09:05:20PM +0200, Giovanni Bracco wrote:
>> Thank you for the suggestion, but I have tried to use the command
>>
>> fs setcrypt -crypt off
>>
>> on 1.8.x clients
>>
>> and
>>
>> fs setcrypt -crypt
>>
>> on 1.6.x clients
>>
>> without any effect on performance in both cases, no increase for  1.8.x
>> and no decrease for 1.6.x
>>
>> Is that the way to control the encryption, isn't it?
>>
>> In both cases I have checked the status with fs getcrypt
>>
>> Giovanni
>>
>> On 13/10/20 19:48, Benjamin Kaduk wrote:
>>> On Tue, Oct 13, 2020 at 09:42:14AM -0400, Jeffrey E Altman wrote:
>>>> On 10/13/2020 9:28 AM, Giovanni Bracco (giovanni.bracco@enea.it) wrote:
>>>>> I have seen that the first release of OpenAFS 1.9.0 is out and so I
>>>>> thought that it was time to try at least 1.8.x and also 1.9 on our
>>>>> production Linux x86-64 nodes, where we have used 1.6.x up to now.
>>>>>
>>>>> Our AFS cell has file servers with OpenAFS 1.6.x and while over WAN the
>>>>> performance can be rather poor, due to the well known rx latency
>>>>> problem, in the LAN we have values between 70 e 80 MB/s both for read
>>>>> and write. The clients are CentOS 6.x and 7.x all with OpenAFS 1.6.x.
>>>>>
>>>>> So we have tried OpenAFS 1.8.6 clients on some production nodes (from
>>>>> CentOS 7.3 to 7.8) and the performance on LAN have been poor, 15 MB/s
>>>>> while the same nodes with 1.6.x clients has the normal performance.
>>>>>
>>>>> Then we have installed a test AFS cell with OpenAFS 1.8.6 but no change
>>>>> and at that point I we have checked also on user desktops using ubuntu.
>>>>> 1.8.4 and the performance are as low as for production nodes with 1.8.x
>>>>> release.
>>>>> No improvement going to 1.9.0 (both server and clients) either.
>>>>>
>>>>> Any suggestion?
>>>>> Are we missing something important?
>>>>> No special tuning in our installation.
>>>>>
>>>>> Giovanni
>>>>
>>>> I suspect the observed performance difference is due to:
>>>>
>>>> commit 6d59b7c4b4b712160a6d60491c95c111bb831fbb
>>>> Author: Benjamin Kaduk <kaduk@mit.edu>
>>>> Date:   Sun Jul 30 20:57:05 2017 -0500
>>>>
>>>>     Default to crypt mode for unix clients
>>>
>>> I agree, though I probably would have copied the relevant text from the
>>> 1.8.0 release notes:
>>>
>>>     All Client Platforms
>>>
>>>       * Use rxkad_crypt by default for connections to fileservers.  This matches
>>>         the existing behavior of the Windows client and has been applied by
>>>         the distribution packaging on many platforms already.
>>>
>>>
>>> -Ben
>>>
>>
>> -- 
>> Giovanni Bracco
>> phone  +39 351 8804788
>> E-mail  giovanni.bracco@enea.it
>> WWW http://www.afs.enea.it/bracco

-- 
Giovanni Bracco
phone  +39 351 8804788
E-mail  giovanni.bracco@enea.it
WWW http://www.afs.enea.it/bracco