This one may be considered as a testcase for I/O system optimization.

It is taken from the binutils testsuite, ld/ld-elf/sec64k.exp, where this test may occasionally trigger a timeout. It is extracted from cdf7c161ebd4a934c9e705d33f5247fd52975612 sources, 2010-10-24.

$ wget -O - http://www.gnu.org/software/hurd/open_issues/performance/io_system/binutils_ld_64ksec/test.tar.xz | xz -d | tar -x
$ cd test/
$ \time ./ld-new.stripped -o dump dump?.o dump??.o
0.00user 0.00system 2:46.11elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+0minor)pagefaults 0swaps

On the idle grubber, this one repeatedly takes a few minutes wall time to complete successfully, contrary to a few seconds on a GNU/Linux system.

While processing the object files, there is heavy interaction with the relevant ext2fs process. Running rpctrace on the testee shows that (primarily) an ever-repeating series of io_seek and io_read is being processed. Running the testee on GNU/Linux with strace shows the equivalent thing (_llseek, read) -- but Linux' I/O system isn't as slow as the Hurd's.

As Samuel figured out later, this slowness may in fact be due to a Xen-specific issue, see Xen lseek. After the latter has been addressed, we can re-evaluate this issue here.