those numbers seem implausible. I just tried my standard quick NFS test on the same file system with sec=sys and sec=krb5. It untar's a file with 80,000 files in it, of a size typical for our users. krb5: 1:38 sys: 1:29 I did the test only once. Since the server is in use, it should really be tried multiple times. krb5i and krb5p have to work on all the contents. I haven't looked at the protocol details, but krb5 with no suffix should only have to work on headers. 3.2 msec increase in latency would be a disaster, which we would certainly have noticed. (Almost all of our NFS activity uses krb5.) It is particularly implausible that latency would increase by 3.2 msec for krb5, 0.6 msec for krb5i and 1.6 for krb5p. krb5 encrypts only security info. krb5p encrypts everything. Perhaps they mean 0.32 msec? We'd even notice that, but at least it would be consistent with krb5i and krb5p. From: Wang Yugui <wangyugui@xxxxxxxxxxxx> Sent: Sunday, February 12, 2023 1:01 AM To: linux-nfs@xxxxxxxxxxxxxxx <linux-nfs@xxxxxxxxxxxxxxx> Subject: question about the performance impact of sec=krb5 Hi, question about the performance of sec=krb5. https://learn.microsoft.com/en-us/azure/azure-netapp-files/performance-impact-kerberos Performance impact of krb5: Average IOPS decreased by 53% Average throughput decreased by 53% Average latency increased by 3.2 ms and then in 'man 5 nfs' sec=krb5 provides cryptographic proof of a user's identity in each RPC request. Is there a option of better performance to check krb5 only when mount.nfs4, not when file acess? Best Regards Wang Yugui (wangyugui@xxxxxxxxxxxx) 2023/02/12
