[OpenAFS-devel] how does fileserver read from disk?

[Tom Keiser]

On 9/21/05, chas williams - CONTRACTOR <chas@cmf.nrl.navy.mil> wrote:
> In message <217964d6050921143635c11c6@mail.gmail.com>,Tom Keiser writes:
> >Have you ever taken a close look at FetchData_RXStyle in
> >afsfileprocs.c?  Did you notice how it calls readv(); rx_Writev() in a
> >tight loop?  Did it ever occur to you that this is horribly
> >inefficient?  What is the kernel disk io scheduler doing when we're
> >busy in a sendmsg() syscall?  If it actually bothers to do something,
>
> the fileserver is threaded.  i would call it somewhat similar to
> an nfs file server.  several threads are waiting for requests.  when
> one is busy the others are free to handle requests.  thus the tuning
> for number of nfsd's in early servers.
>

ok. well, I was talking about the latency for one call.  sure, we're
doing a pretty good job of parallelizing multiple calls.  I was simply
trying to point out that the latency for a single call to complete
could be made lower through added parallelism and asynchrony.

> >No.  Optimal read-ahead knowledge does not exist, courtesy of the
> >halting problem.  Of course, the fileserver's kernel knows less than
>
> the fileserver basically knows how much a client has requested and that
> it can only fulfill a certain fixed amount per fetchdata.  if the client
> made a request bigger than this fixed amount, i suppose the fileserver
> could read and cache that amount from the file the knowing that the
> client will just ask for the rest.  i suppose you could just read the
> "right" amount anyway and rely on your operating system's disk block
> caching to keep the data available for subsequent calls.
>

Yeah.  It will take a lot of research and prototype development to
know for sure whether buffering, cache, aio, or any combination of
them give sufficient performance improvements for a "general" workload
to justify the increase in code compexity.  I'm not trying to claim
that any particular solution is going to offer us the holy grail of
performance.  I just wanted to gauge people's reactions to making the
fileserver more complicated and asynchronous.

--
Tom Keiser
tkeiser@gmail.com