I sent some advice via other channels, but Marcus's lengthy comments
are mostly accurate and worthwhile. However, this statement is not
completely correct:
Marcus Watts <[EMAIL PROTECTED]> writes:
> there is little advantage to multiple I/O paths simply for
> pure "file server" use. The file server runs as a user
> level process, so all reads and writes are "synchronous".
> Unless the read is in the buffer pool (and it probably
> isn't because it wasn't in your client's cache,) it
> has to block for the read, and nothing else is going to
> happen until that read returns. Writes could in theory
> proceed asynchronously. However, the file server does
> "fsync"s after writing each chunk, so it's still going to block
> until the data reaches the disk. So, so far as the file
> server goes, the only thing that counts is how fast a single
> read or write is, not how many reads or writes it can have
> pending.
The server's local filesystem will try to prefetch some of the
disk blocks into the buffer cache. How frequently this works depends
on the particular server filesystem implementation, but I would bet
that quite a few reads are satisfied by the buffer pool. Those
prefetches all happen asynchronously to the server process. Also,
writes do proceed asynchronously. The file server doesn't fsync after
each chunk unless the application at the client has explicitly called
fsync. In AFS 3.4, stores of adjacent chunks are coelesced into a
single RPC, and the fsync is only done (if at all) when the RPC
completes, so even in that case, there is the opportunity for quite a
bit of disk activity asynchronous to the server process.
That said, I think the speed of a single read or write probably is a
more important than the number of reads or writes that can be pending
at any one time. Given the current file server implementation it
seems unlikely that there will be more than three or four disk
operations proceeding simultaneously, except in a very well-tuned
write-intensive environment.
John Hascall <[EMAIL PROTECTED]> writes:
> Another factor which may concern you is the time to boot
> a server after a crash (or downtime). Having lots of
> disks (esp, if they have lots of volumes) can make
> starting the fileserver take a very long time (insert
> standard plea for transarc to change how volumes are
> attached).
We have ameliorated this in 3.4. Basically, the fileserver processes
RPCs and attaches volumes simultaneously while restarting. So volumes
on partition /vicepa will be available before volumes on partition
/vicepz. But that's still good advice, since all partitions must
still be salvaged before the fileserver will start attaching any
volumes.
