The file systems were created with the standard Linux mkfs.ntfs and mkfs.ext4 commands; I modified the NTFS “sector size” and the EXT4 “block size” defaults, but assume that both of those refer to block size and not physical sector size. Each file system was given a blank 10GB partition which was not written to before the test. I performed the test with a shell script (attached) that mounted each partition, moved the IOzone binary to it, ran the benchmark, and copied the results file to my home directory.
The benchmarks that were taken in this test were: write speed, read speed, rewrite speed, reread speed, random read speed, random write speed, and strided read speed. Although I believe that other data such as CPU usage or disk latency would have been valuable, only disk transfer rate was recorded.
Finally, IOzone does not speak to statistical variance in its documentation; I am not sure if a repetition of a test would yield the same data, although I attempted to minimize all other variables and believe that recollected data would at least be similar.
The results of the test were disappointing, and perhaps speak to the futility of "tuning" modern file systems. I used as many block sizes as the tested file systems would allow, and expected a noticeable shift in performance when reading and writing larger file sizes, but this, overall, was not the case. EXT4 did achieve increased write speed with a block size > 1KB, but the speed of all the other tests on it actually decreased. NTFS had increased performance with larger block size, but NTFS with 512B block size had the highest reread performance of any of the tested settings; its random read performance was also among the highest, although those did not vary much.
While I did not perform a test that attempted to read multiple smaller files—a more commonly performed task for most purposes—I was more interested to see whether there was a benefit to larger block size than whether there was a drawback. Having not found much of a benefit means that testing for such a drawback would be pointless; there is no reason to prefer the larger size over the smaller.
This data counters Tanenbaum’s discussion on block size. It seems that modern file systems and operating systems cache, read ahead, and otherwise work around block size to the point that it is almost insignificant in the performance of a block device. Further, with the size of modern hard disks, it seems that the discussion on the size/space tradeoff of hard disk block sizes is moot. In order to eke greater performance from hard drives, one must look at tunables other than block size.
Footnote about looking at the actual data: It is space-delimited, so while it can be opened as a text file, it’s a lot nicer to look at if you import it into Excel or something and tell it to split on spaces (and then trim out the irrelevant text at the top).
One more footnote: I just realized that I was writing the benchmark data to a file on the same partition and drive. Oops. I don't think it should have done much, though.
![[paper clip]](/courses/source/wiki_images/paper_clip_tilt.png)
name last modified size
