Comment by ryan-c
10 years ago
(I wrote this horrible thing)
It's pretty horrendously bad on spinning rust - you get very, very close to 100% fragmentation, so the disk has to seek for each cluster. A lower bound average on seek time is probably something like 4ms, so your max transfer rate is going to be limited to 125 * cluster size. Depending on the disk size[0] the cluster size may be up to 32KB, so we're looking at maybe 4MB/sec best case. I'd guesstimate it'd increase boot time by somewhere between 10x and 40x.
In theory, you could make the disk performance even worse by alternating between the beginning and end of the disk, though you may need to do a little tweaking to ensure this doesn't inadvertently allow read-ahead to help.
That might not work given that the drive might have more than one platter. You'd probably want to know how many heads the drive has to determine how to stripe it in the most inconvenient way possible. I think going beginning to middle on a single platter and back for each file would be the best way to get the worst performance for each file. That'll make sure it has to seek for each subsequent block and it can't inadvertently get read-ahead since it has to back track all the time, and the separation should be far enough that it won't get it on the in order blocks either.
EDIT: Just realized that I don't think this can be done through normal means. I think it'd need a pathological FAT file system driver to do it, and you'd have to build the image ahead of time to do it.
I seem to recall that this was very bad juju for old HDDs, in that it would quickly wear out the mechanics of the RW arm.
There are stories of really old hard drives being made to move around a room with abusive disk access patterns.
http://www.catb.org/jargon/html/W/walking-drives.html
1 reply →
That sounds plausible. I'm curious how you tested this. Do you have a FAT-formatted disk to play with, or did you do this in a VM, or...?
I wonder how much effect it'd have on an SSD. Those tend to have much higher random read and effective seek times far below 1ms.
You might assume that it would have no effect, but an SSD reads data in a block. If the size of each fragment is smaller than a block then it will definitely slow it down.
But it depends on how large a block is on the SSD.
I think SSDs call them pages. Some brief googling seems to indicate that 16KB is a common page size, so if the cluster size is also 16KB it's probably not too bad.