Re: [9fans] du and find

[erik quanstrom <quanstro@quanstro.net>]

> On Fri, Jan 01, 2010 at 09:02:28PM -0500, erik quanstrom wrote:
> > > you've got a fast system.
> > > in at least one system i use, du -a of /sys/src takes about 25s.
> >
> > i have a humble 2y.o. single-core 35w celeron as a fileserver.
> >
> Speed of `du' depends on I/O, not CPU.

really?  have you tested this?  i've always found the
two to be related.

first, most fileservers have an in-memory block cache.
unless your active set is really big, most directories should
be in the in-memory cache.

when in memory cache, the time it takes to acquire
block cache locks and copy data dominates.  for
fossil+venti this factor is multiplied by 2 plus 2 trips
through the kernel.  so for memory-cached blocks,
fileserver speed is entirely dependent on network+
cpu.  the proportion of memory cache is of course
proportional to one's cache sizes.

sure, you can take this to extremes where the size of
the memory cache is so small, that the memory cache
doesn't matter, or the speed of the network is so slow
(find /n/sources) that nothing other than disk io or
network speed matters.

second, each directory read requires a number of 9p messages.
in the current system, each incurs the full rtt penality.
so the network latency is a really big factor in du
performance.

you can test to see how the du speed is related to
network performance very easily if you have the right
sort of network card.  just adjust the interrupt coalesing
values.  (Tidv/Tadv in ether82563, or
echo coal $µs>/net/ether$n/clone for etherm10g)

and the cool thing is that especially for tcp, i've
found cpu speed and network latency to be pretty
imporant.

- erik