Fast File System throughput
speck at cit-vax.ARPA
speck at cit-vax.ARPA
Wed Jul 25 09:20:09 AEST 1984
From: Don Speck <speck at cit-vax.ARPA>
Mkfs (and hence newfs) set the rotational delay parameter of a new
filesystem to 4ms. One presumes that this value was chosen to give the
maximum transfer rate from the disk. It appears to be the same value
used to generate the results in the paper "A Fast File System for Unix",
where they got a throughput of 116 4Kbyte blocks per second from a disk
with 16Kbytes per track and 16.67ms per revolution (hence 4.17ms between
blocks).
But I've been unable to duplicate their results. On our CDC 9775
Winchester, I can't get more than about 40 4Kbyte blocks per second
with the default parameters. A 9775 spins at the same rate and has
the same number of blocks per track as the disk in the paper.
I made a filesystem on an "a" partition with "newfs -b 4096 -f 1024",
created a file with 6400K-bytes of garbage, and read it with a trivial
program that does read() in a tight loop and nothing else, with read
sizes of 2^n (11 <= n <= 16), and got the same results for each n tried:
a throughput of only about 40 4Kbyte blocks per second (idle machine).
After I do "tunefs -d 7" on the filesystem and recreate the file, the
throughput almost doubles. Apparently 4ms is just not enough time for
the machine to get ready to read the next block. Trying it on an Eagle,
about half of the 4Kbyte transfers take more than 5ms to set up.
Is there something wrong with our configuration that makes it take
longer than 4ms to set up a 4K-byte transfer? The configuration is:
a CDC 9775 mapped as two RM05's, a CDC 9766, and an Eagle all on one
SI 9900 controller on mba0, TU77 tape drive on mba1, one unibus with:
5 Dec DZ's, 3 Ether boards (en0, il0, il1), LH/DH imp interface, two
brand-X LP-11's, and a Versatec; VAX/780 cpu running 4.2bsd, kernel
options: COMPAT,INET,PUP,QUOTA, and 16 megabyte data space. No quotas
on the partitions tested. Test was done on a quiet Sunday evening when
there was 97% idle time and no other disk I/O aside from /etc/update.
Does anyone see a reason why our 780 can't get as much filesystem
throughput as the 750 that generated the results in the paper?
Don Speck
More information about the Comp.unix.wizards
mailing list