> i would imagine that cpu has nothing to do with it and encryption > would add no overhead at all. i would image that seeks dominate > your performance numbers.
Well, there are numerous issues. The machine is a CPU server booting off another fossil/venti host; it has its own rather pristine, mostly unused Plan 9 distribution and a few other fossil partitions of which only one is backed by venti. I am hesitantly initialising the dump partition because I'm not convinced I have the efficient direcory hierarchy I want to live with. I can't easily check before fossil is active, but venti takes a long time to start and by the time the machine is "ready", memory is full and half of swap is in use :-( During "snap -a" load, context switching and interrupts tend to swing wildly and swap is often being accessed (it's on IDE and the drive light can only mean swap access, I do have DMA active :-) So I would not use this particular configuration to win any competitions. In passing, the first time I did this, I powered the machine down a few times because I was convinced it had stalled. That might have been pessimism on my part, because now that I am monitoring it (stats), it is clear that it occasionally shows no sign of disk activity (no seek, load in astronomical places) for long periods, only to proceed again later. But I do turn all snaptimes to none, which I superstitiously did the first time and seemed to make a difference (I bet it didn't, but if anyone suspects that a dump should finish before another starts, I have the equipment to test the theory. ++L
