I recently started trying to run a Sun Fire X4100, with amd64 5.2. I did a large data transfer to it, to a filesystem (FFS with no particular options) mounted -o async. The machine has way more than enough RAM to buffer everything I copied, so the copy completed reasonably quickly, limited mostly by the sending system's disk (the network was running gigabit). But, all through it, I was seeing
sd1(mpt0:0:1:0): adapter resource shortage appearing once a second on the console (sd1 is the drive I was copying to, the one mounted -o async; the OS is on sd0). These stopped when the transfer finished; when I told it to sync, in preparation for unmounting, they started again, and, watching the disk's busy light, I would estimate it is busy between 1/3 and 1/2 the time with a cycle time of about 1Hz, which is cripplingly inefficient. Reading the code leads me to suspect this is a perfectly normal resource shortage in the presence of more transfers pending than the hardware can handle. However, arguing against this are (a) that someone felt that message worth printing and (b) that the recovery mechanism is a huge performance-killer, apparently locking up all transfers to that drive for an entire second. (At least, that's what the code appears to be doing, and it matches well enough with the behaviour I saw.) I'm tempted to rip out the message entirely and decrease the wait time drastically, probably somewhere in the 10-to-100 millisecond range, so that it normally wakes up before the previous transfers have completely drained. But I am hesitant to do this without having some idea why it's set up the way it is. (It'd be a gross kludge anyway; the right answer, it seems to me, would be to issue transfers as the existing ones finish, rather than just waiting and retrying. But it would be an acceptable workaround in this case.) So, what's the scoop with this? Would rolling back to 4.0.1 help any? It is known to run at leas tminimally on that hardware, though I haven't stress-tested it enough to know whether it'd exhibit the same issue. (A quick glance at the code leads me to suspect it would.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
