[OpenAFS] strange disk write activity compared to network bandwidth

Lars Schimmer l.schimmer@cgv.tugraz.at
Mon, 27 Aug 2007 16:57:20 +0200

Hash: SHA1

Sophana wrote:
> Hi
> I'm evaluating openafs 1.4.4 performance on centos 4
> I noticed some strange things.
> I'm doing a simple svn checkout (meaning write to afs) (server on the
> lan)  of a lot of source files (quite small...) (about 50mbyte+svn
> overhead ~=3D 100mbyte)
> When using gkrellm, I can see the disk write bandwidth at at a high
> level (> 15mbyte/s), almost no read, and the network bandwidth is MUCH
> lower (less than 1mbyte/s). It seem that the server is busy making a LO=
> of disk writes, that are about 10 to 20 times the volume of the real
> data being written.

Part one: gkrllm is HEAVY out of real data. It often shows data of 12-14
MB/sec on my 100MBit line. So don't trust gkrellm. Reduce the value on
about 10-20%.

> And of course, it is quite slow:
> 3min on remote afs client (standard cache settings)
> 2m30 on the server itself
> 21s when checking out to an ext3 partition.
> Has someone an explanation of that behaviour? and a workaround?
> It seems that when I tested openafs 1.2.X a long time ago, I think ther=
> were not such strange behaviour.

You said it, a lot of small files. The overhead for a lot of small files
is huge on OpenAFS - check if its in the cache, cache-writing, writing
from cache into server.... That takes time.

And at least I know there are some "special files" within SVN checkouts.
 I don't know it exact, but SVN co with tortoiseSVN on windows onto AFS
space was always kinda flawky with my system (although haven't tested it
for the last 5-10 revisions of OpenAFS).

> Thanks

Lars Schimmer
- --
- -------------------------------------------------------------
TU Graz, Institut f=FCr ComputerGraphik & WissensVisualisierung
Tel: +43 316 873-5405       E-Mail: l.schimmer@cgv.tugraz.at
Fax: +43 316 873-5402       PGP-Key-ID: 0x4A9B1723
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org