On Monday, June 20, 2005 04:55:01 PM +0200 Niklas Edmundsson
<[EMAIL PROTECTED]> wrote:
On Mon, 20 Jun 2005, Roland Kuhn wrote:
What kernel? What underlying filesystem?
vanilla 2.4.31, reiserfs.
Our experiences of reiserfs are not that great, I would really recommend
you to try another underlying fs.
The performance figures you mentioned when talking directly to the
raid, are they when doing IO on a filesystem that are similar to the
AFS IO pattern (ie accessing a large number of small files)? Streaming
IO figures are more or less uninteresting when doing AFS in our
experience.
I haven't had a look yet, but I thought the files were stored also as
files in /vicep*? Our files are 1.5GB each, so streaming reads should
be what we need, right?
Does AFS store those files as large continous files too? Poke around in
/vice* and find out (or maybe someone on the list will answer :). I have
no clue on how the fileserver manages requests too, worst case it would
do open/seek/read/close for each chunk, but I hope that it's smarter than
that even though it's a kludge.
The fileserver does store files as large continuous chunks. And, it caches
open file handles, so if you are actually reading from a big file at a
reasonable rate, it shouldn't need to do open/close on every access. It'll
need to seek, probably, but that doesn't actually have a performance impact
on regular files.
However, the cache manager does reads with one RPC per chunk, so normally
one chunk has to be completely read before you can start asking for the
next one. That means you don't get to stream across chunks, which can
hurt. You can improve the situation somewhat by using a larger chunk size,
but that has its own problems.
-- Jeffrey T. Hutzelman (N3NHS) <[EMAIL PROTECTED]>
Sr. Research Systems Programmer
School of Computer Science - Research Computing Facility
Carnegie Mellon University - Pittsburgh, PA
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
