[OpenAFS] Re: Server disk operations speed

[Jukka Tuominen]

> On Tue, 9 Apr 2013 21:55:40 +0300 (EEST)
> "Jukka Tuominen" <jukka.tuominen@finndesign.fi> wrote:
>
>> One thing I noticed immediately was that by disconnecting the server
>> machine's NIC (VM though), I couldn't reach /afs/ contents any more,
>> even if the machine contains all servers (services) and a client. Is
>> that the expected behaviour?
>
> The client contacts the VLDB through the IP address listed in your
> CellServDB (or via AFSDB or SRV records in DNS). The client contacts the
> fileserver via the IP addresses the fileserver detects at startup
> (roughly), or what's in the server's NetInfo file.
>
> So, if that machine can't reach that IP when the NIC is disconnected,
> then yes, that's expected.

OK, that's good to know. I believe there's propably a mixture of local
IP's, external IP's and DNS names currently, which I will go through.

Does it sound resonable to prefer DNS names over external IP's, and
external IP's over local IP's? The rationale there would be to prefer
dynamic over static definitions, and IP's that the clients can see over
local IP's that may not be accessible always? (external meaning WAN and
internal LAN IP's). I've started with whatever worked, and later on moved
towards what I just described.

If you just want to see where the traffic is
> going, capture some net traffic. All AFS traffic for a client
> interacting with a server should happen on ports 7000-7003 UDP. If we're
> contacting an IP that is one of the local host's interfaces, it's up to
> the underlying OS where the packets physically go.

OK, I'll try to figure out how to do that. Wireshark is my guess to start
with.

>
>
> And just by the way, I think it's probably a much better use of your
> time to look at the data flow and try to see bottlenecks than just
> fiddling around with server/client parameters. You don't really know
> what parameters could change anything (if you change every single
> runtime switch, you're going to be testing things for a while), and you
> don't even know if the performance bottlenecks are anywhere in the
> openafs software.

I definitely agree on this. Bottlenecks first, optimization second. Even
if the optimizer is automatic and should handle complex combinations...
maybe.

br, jukka

>
> --
> Andrew Deason
> adeason@sinenomine.net
>
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>