[OpenAFS-devel] RE: Backups using commercial products

[Sam Hartman]

>>>>> "Mitch" == Mitch Collinsworth <mitch@ccmr.cornell.edu> writes:

    Mitch> On Tue, 2 Jan 2001, Neulinger, Nathan R. wrote:

    >> What I wonder is - how hard would it be to access the contents
    >> of an AFS volume from a file server, without going through AFS
    >> itself - i.e. by direct file access - sortof a really fast 'vos
    >> dump' equivalent.

    Mitch> The other path to consider is that now that we have the
    Mitch> source maybe someone will figure out why vos dump is so
    Mitch> slow and fix it.

I've been looking at this some partly as a learning exercise for
understanding RX internals.  I have profiling data of a volserver with
me running vos dump available at
http://server1.boxedpenguin.com/~hartmans/volserver.gprof.  I think that gprof isn't quite dealing with LWP correctly, but the data looks approximately useful.

I was trying to dump a volume onto the same machine I was running the
volserver on.  I noticed that the dump tended to be fairly CPU-bound,
which was surprising; I would expect that in the ideal case things
would be disk bound.

The vos process also used a lot more user time than I would have
expected, again I would expect most time to be in system calls.


Nothing really jumps out.  The code calls iomgr_poll at least once
pervnode (if skipping) and once per successful write.  That seems
excessive, but since it isn't really creating a noticed performance
problem, I guess it is OK.

The profile data makes it look like the RX receive codepaths are
taking too much time.  However, I believe this is misleading; it seems
that path tends to start sending packets as well, and it is not
surprising that dump spends a lot of time sending packets.

Anyway, I'll let you know if I actually find something.