[OpenAFS] Server disk operations speed

[jukka.tuominen@finndesign.fi]

>> So, I thought that the network communication was the bottle neck,
>
> That is easy enough to test with methods that don't involve AFS or even
> disk operations.  ttcp, for example.
>
>> but just in case I tested whether it's the server itself that was
>> somehow
>> exceptionally slow.
>
> And of course you have other means of testing disk access speeds too that
> don't involve AFS or the network.

OK. My point was just that while on the plain unix side, both the network
and disk speed seem to be working reasonable well, why the afs speed is so
much different. For the benefits of afs, I'm fine with 1/2 or 1/4
performance of say, NFS counterpart. Once I made the original
kerberos/openafs/openldap installation, I was sure to make stupid mistakes
that I'm now trying to recover.

>
>> I copy/pasted the earlier mentioned test directory
>> (see the full message below) first in the normal unix environment
>> /home/user/...(source and target), which turned out to be extremely fast
>> (HW supported virtualization on a SSD disk). So, no problem there.
>
> My "what exactly did you do?" question was aimed at this.  It is not
> obvious from your initial message what the steps were that you took to
> copy materials, and it is only marginally more apparent from this.
>
> So, what you are saying is that you did something for which it is not
> possible to describe the steps as commands on the command line because
> they weren't, but rather UI interaction on GNOME or something similar?
>
> (I would have liked to see the commands, that is, and a description of
> the sources and targets in each case.)

For the GA optimizer I used Racket language, and copy-directory/files
command, that would be propably close to the command line cp. Again, I'm
not looking for a super optimized speeds (for the time being), just to get
the magnitude right.

>
>> Then I got access to an afs account on the same machine (kinit; aklog),
>> and copied the same test directory in /afs/cell/user/...(source and
>> target) which turned out to be extremely slow.
>
> If I am correct in that you are using the GUI to do this, would it be
> possible for you to repeat the test in a way that does not involve the
> GUI?  In reference to a recent conversation here, it is my experience
> that GUIs such as Nautilus etc attempt to analyse the contents and
> permissions of the filesystems involved in ways that don't play well
> with AFS, and before we come to the conclusion that your AFS server
> isn't performing, I'd like to cut out at least one obvious middleman.

For the quick and dirty unix/afs comparison I did use Nautilus, but even
then, shouldn't the afs figure be significantly higher. The unix-side test
was just to check if the server itself was OK, I'm not expecting the same
figures from afs.

>
>> All this took place on the very same server machine, without any
>> external
>> clients. I do suspect that in afs case, some traffic _may_ leave the
>> machine (use dns to find the external address and return back to the
>> very
>> same machine, maybe...), which may explain partly the results.
>
> That would be trivial to observe using any network debugging tools such
> as wireshark/tcpdump.  Also, if you keep vmstat 10 running on the server
> during your tests and post the results, that might be enlightening.

Let me put it this way: if it were to leave the server, would it be doing
something it shouldn't, i.e. a possible reason for the problems?

>
>> I'm a bit puzzled since everything works, but annoyingly slowly for
>> serious use. Of course my main concern is the speed for clients, not
>> within the server.
>
> If you use another client machine and carry out the exact same tests,
> is the performance worse / as bad/good / better?

Worse: 100-400KB/s over 54Mb WLAN (Nautilus, sorry :)

>
> (BTW If you don't mind, I would appreciate it if we kept the conversation
>  on the mailing list only - I don't need an extra copy in my inbox.
> Thanks.)

Sure thing, np.

br, jukka

>
> BR Atro
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>