When I was younger, my friends and I joked about making a "Disk Fragmenter" which would enumerate through every file on the disk and split them into non-contiguous clusters to make sure that the actuator arm on your platter-drive gets a PROPER WORKOUT TO FEEL THE BURN.
Such tools really exist and they're used for testing file systems, so that you have a more realistic "aged" layout on a freshly created test file systems.
We also have memory fragmenters to do the same for memory for the same reasons.
Would those tools be primarily proprietary, or do some live in the open-source world too? I’d be interested in the techniques they use to aim for realism there.
Admittedly I haven’t made much of a search, but various search engines and autocorrects seem really convinced that I mean “defragmenter” instead of “fragmenter,” despite myself…
I recall there being some techno-mysticism surrounding defragging regarding how often and when it was necessary, what it did and didn’t help, etc. I also remember the claim “Macs don’t need defragging” but I don’t know if HFS(+) was actually any less prone to fragmentation than FAT32 was. Companies like Symantec were happy to sell defragging tools to Mac users regardless.
Perhaps it's appropriate for me to link to the free game I made where you play a taxi driving through Disk Defragmenter and delivering stray blocks of data to their final locations: https://safetystoatstudios.itch.io/ddr. It was pretty fun to watch Defragmenter as a kid, but it would have been better if it was interactive, kind of like the 3D maze screensaver.
The speed is determined by a simple 1000 / <iops> per disk (there's different disks if you click "Settings").
If you inspect and go to sources and look for "1e3 /" you'll find the line responsible, you can set a breakpoint and change e.disk.iops to 1000 which will make the timeout per row 1s instead of 2-4s, so the whole thing goes faster.
I love it. A couple notes:
- This is about 10x a real defrag speed - WAAAY too fast
- IIRC the "Data that will not be moved" was typically lumped at the beginning of the drive, not spread out all over.
I'm a stickler for accuracy too. The defragged blocks in the original Win9x program weren't solid blue - they had a hatch pattern texture to them. I remember it way too vividly.
Source: Watching a disk defrag was every millenial kids equivalent of going to the laundromat and watching laundry tumble.
here is another version i found when googling these things that seems somewhat similar, but with a few more "accurate" features. also, has the source available in a single file.
Typically it would be getting some bits from other parts of the drive and there would be a few (that many) bits it wouldn't move because they were the swap file and DOS boot system files.
Fragmentation is an issue with any file system. SSDs dramatically reduce the cost of fragmentation but do not eliminate it, as non-sequential access is still slower than sequential access.
FAT32 allocates the first free block. IIRC, file order must match disk order because reasons. Ext2 prioritized allocating the middle of free space to allow fragment-free growth on both sides and it became a standard filesystem feature after that.
When I changed it between drives and back I lost my progress :/
We also have memory fragmenters to do the same for memory for the same reasons.
Admittedly I haven’t made much of a search, but various search engines and autocorrects seem really convinced that I mean “defragmenter” instead of “fragmenter,” despite myself…
Actually here is a recent paper discussing this (although the basic concept is much older):
https://arxiv.org/abs/2401.08858
afaics all that meant was file allocations make a little extra space at the end, so if the file expands it doesn't need to allocate a new block.
If one keeps files around for a long time and constantly adds to them, then the files get fragmented on any filesystem.
The only way to avoid this is pre-allocate all files to their maximum possible size and never exceed that size.
If you inspect and go to sources and look for "1e3 /" you'll find the line responsible, you can set a breakpoint and change e.disk.iops to 1000 which will make the timeout per row 1s instead of 2-4s, so the whole thing goes faster.
Source: Watching a disk defrag was every millenial kids equivalent of going to the laundromat and watching laundry tumble.
https://youtu.be/dc_SDyLYq3U?t=347
https://morello.dev/blog/defrag98-rebuild
what it looked like before
https://morello.dev/blog/windows-98-defrag-simulator
a previous discussion:
https://news.ycombinator.com/item?id=40962195
here is another version i found when googling these things that seems somewhat similar, but with a few more "accurate" features. also, has the source available in a single file.
https://horatioconkerhead.github.io/win98-defrag/
if you want the real deal, you can run windows 95 in the browser quick. it took running it a few times to get it to actually defrag:
https://archive.org/details/win95_in_dosbox
https://en.wikipedia.org/wiki/Interleaving_(disk_storage)
I did it in computer lab and showed others and the teacher lost it, thought we were breaking things.
Typically it would be getting some bits from other parts of the drive and there would be a few (that many) bits it wouldn't move because they were the swap file and DOS boot system files.
Per-drive individual sounds, and BSoD included. Nice touches, love it!
As great as it is, way too fast.
I’m going to watch Johnny Castaway now.
If AI generated this is what the AI revolution is all about.
Can we get a cross platform screensaver?