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

[Roland Kuhn]

Hi Chas!

On 16 Sep 2005, at 14:42, chas williams - CONTRACTOR wrote:

In message <[EMAIL PROTECTED] muenchen.de>,Roland Kuhn writes:

Why can't this be replaced by read(big segment)->buffer->sendmsg (small

segments). AFAIK readv() is implemented in terms of read() in the
kernel for almost all filesystems, so it should really only have the
effect of making the disk transfer more efficient. The msg headers
interspersed with the data have to come from userspace in any case,
right?

no reason you couldnt do this i suppose.  you would need twice the

of rx_AllocWritev() that only allocated packet headers and chops up a
buffer you pass in.


memcpy() into the already allocated rx packets.  this had no impact on

really but rather than you only get 1k for each rx packet you process.

level disk driver didnt support scatter/gather you might seem some
benefit from this).

number of entries in the iovec though. you would need a special version curious, i rewrote rx_FetchData() to read into a single buffer and then performance as far as i could tell (my typical test read was a 16k read split across 12/13 rx packets). the big problem with iovec is not iovec it quite a bit of work to handle an rx packet. (although if your lower

Ciao,
                    Roland

--
TU Muenchen, Physik-Department E18, James-Franck-Str. 85747 Garching
Telefon 089/289-12592; Telefax 089/289-12570
--
A mouse is a device used to point at
the xterm you want to type in.
Kim Alm on a.s.r.
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12

PGP++ t+(++) 5 R+ tv-- b+ DI++ e+++>++++ h---- y+++
------END GEEK CODE BLOCK------

I know already that 16k-reads are non-optimal ;-) What I meant was doing chunksize (1MB in my case) reads. But what I gather from this discussion is that this would really be some work as this read-ahead would have to be managed across several rx jumbograms, wouldn't it? GS/CS/M/MU d-(++) s:+ a-> C+++ UL++++ P-(+) L+++ E(+) W+ !N K- w--- M + !V Y+

PGP.sig
Description: This is a digitally signed message part