* [PATCH] afs: Fix fileserver probe RTT handling
@ 2022-11-28 17:04 David Howells
0 siblings, 0 replies; 2+ messages in thread
From: David Howells @ 2022-11-28 17:04 UTC (permalink / raw)
To: marc.dionne; +Cc: dhowells, linux-afs, linux-fsdevel, linux-kernel
The fileserver probing code attempts to work out the best fileserver to use
for a volume by retrieving the RTT calculated by AF_RXRPC for the probe
call sent to each server and comparing them. Sometimes, however, no RTT
estimate is available and rxrpc_kernel_get_srtt() returns false, leading
good fileservers to be given an RTT of UINT_MAX and thus causing the
rotation algorithm to ignore them.
Fix afs_select_fileserver() to ignore rxrpc_kernel_get_srtt()'s return
value and just take the estimated RTT it provides - which will be capped at
1 second.
Fixes: 1d4adfaf6574 ("rxrpc: Make rxrpc_kernel_get_srtt() indicate validity")
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Marc Dionne <marc.dionne@auristor.com>
cc: linux-afs@lists.infradead.org
---
fs/afs/fs_probe.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/afs/fs_probe.c b/fs/afs/fs_probe.c
index c0031a3ab42f..3ac5fcf98d0d 100644
--- a/fs/afs/fs_probe.c
+++ b/fs/afs/fs_probe.c
@@ -167,8 +167,8 @@ void afs_fileserver_probe_result(struct afs_call *call)
clear_bit(AFS_SERVER_FL_HAS_FS64, &server->flags);
}
- if (rxrpc_kernel_get_srtt(call->net->socket, call->rxcall, &rtt_us) &&
- rtt_us < server->probe.rtt) {
+ rxrpc_kernel_get_srtt(call->net->socket, call->rxcall, &rtt_us);
+ if (rtt_us < server->probe.rtt) {
server->probe.rtt = rtt_us;
server->rtt = rtt_us;
alist->preferred = index;
^ permalink raw reply related [flat|nested] 2+ messages in thread
* [PATCH] afs: Fix fileserver probe RTT handling
@ 2022-11-28 22:02 David Howells
0 siblings, 0 replies; 2+ messages in thread
From: David Howells @ 2022-11-28 22:02 UTC (permalink / raw)
To: torvalds; +Cc: dhowells, marc.dionne, linux-afs, linux-fsdevel, linux-kernel
Hi Linus,
Could you apply this patch, please?
Thanks,
David
---
The fileserver probing code attempts to work out the best fileserver to use
for a volume by retrieving the RTT calculated by AF_RXRPC for the probe
call sent to each server and comparing them. Sometimes, however, no RTT
estimate is available and rxrpc_kernel_get_srtt() returns false, leading
good fileservers to be given an RTT of UINT_MAX and thus causing the
rotation algorithm to ignore them.
Fix afs_select_fileserver() to ignore rxrpc_kernel_get_srtt()'s return
value and just take the estimated RTT it provides - which will be capped at
1 second.
Fixes: 1d4adfaf6574 ("rxrpc: Make rxrpc_kernel_get_srtt() indicate validity")
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Marc Dionne <marc.dionne@auristor.com>
Tested-by: Marc Dionne <marc.dionne@auristor.com>
cc: linux-afs@lists.infradead.org
Link: https://lore.kernel.org/r/166965503999.3392585.13954054113218099395.stgit@warthog.procyon.org.uk/
---
fs/afs/fs_probe.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/afs/fs_probe.c b/fs/afs/fs_probe.c
index c0031a3ab42f..3ac5fcf98d0d 100644
--- a/fs/afs/fs_probe.c
+++ b/fs/afs/fs_probe.c
@@ -167,8 +167,8 @@ void afs_fileserver_probe_result(struct afs_call *call)
clear_bit(AFS_SERVER_FL_HAS_FS64, &server->flags);
}
- if (rxrpc_kernel_get_srtt(call->net->socket, call->rxcall, &rtt_us) &&
- rtt_us < server->probe.rtt) {
+ rxrpc_kernel_get_srtt(call->net->socket, call->rxcall, &rtt_us);
+ if (rtt_us < server->probe.rtt) {
server->probe.rtt = rtt_us;
server->rtt = rtt_us;
alist->preferred = index;
^ permalink raw reply related [flat|nested] 2+ messages in thread
end of thread, other threads:[~2022-11-28 22:04 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-11-28 17:04 [PATCH] afs: Fix fileserver probe RTT handling David Howells
2022-11-28 22:02 David Howells
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).