> 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
