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…
This makes me wonder at the absurdity (yet plausible implementation??!?!) of a tool to test something like ZFS filesystem limits, as they are quite gargantuan in many possible measures.
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.
I agree. It may sound elitist but back then you need to understand a few concepts to use a computer. From simple things like a filesystem (folders, file, different file types, things my 19 years old nephew don't know), to how to install software, how to download software (!) and then things even a bit more technical: an operative system, how it works, booting, drivers, etc.
Now everything is just easier (which is better for most people!) but I miss the old days.
20 years ago if somebody told you they used Linux it really meant something - they weren't running WSL, they weren't running a VM in EC2, they probably didn't power on and immediately have things working, and they probably learned a ton just getting to a login screen for the first time. Spinning up a VM just doesn't give the same learning experience.
You had to recompile a kernel module to support your dang modem and network card or no networking. X11 was a royal pain cuz there was no it just works desktops.
Package mgmt was a nightmare and dependency based managers like yellow dogs APT and nonexistent redhats rpm didn't exist.
More like than not you had to compile some random a55 tarball from src and hoped ./configure && make && make all would work or spend hours on USENET looking for solutions (or mailing lists!).
That and many desktop PCs making a kind of grinding noise from the floppy drive on start up, along with the bios "BEEP", as the default boot order option was to seek booting from A: (and possibly B:) floppy drives before the hard drive.
I was going to comment this same thing until I saw yours. I miss degaussing... Especially after holding a magnet to the CRT to get it to display fun colors it wasn't meant to and crossing your fingers that the degauss would fix the damage you'd wrought.
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 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.
> The HFS Plus file system transparently defragments files that are less than 20 MiB in size and are broken into 8 or more fragments when the file is being opened.
Which I expect would have significantly reduced the need to defrag and thus reduced the joy of computing. :p
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.
Norton Speed Disk [1] for DOS was more satisfying to watch because it would visualize reads and writes. So you'd see it grab blocks and then smush them together into contiguous areas. The Windows version was not, as I recall, as satisfying.
I love this. However, Amiga’s Reorg program had a vastly better display, with a larger, resizable window and individual pixels instead of large boxes. You could see much more of the disk at once and get a feel for what the entire operation was doing. Large holes would appear in the middle of a hunk of data, then large files would get moved into the hole, leaving new holes where their incontiguous blocks use to be. Defrag was nice. Reorg was captivating. I miss it.
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.
what a delight it was to behold this visualized process of reinstalling order. the music of the hard disk's seeks went from anarchy to harmony. watching the defragmentation felt like taking a cold shower after sweating all day long ...
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.
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.
This seems....wrong? In the start it is writing over data in the start of the disk that has not been read/relocated (some non-free sectors NEVER light up as "Read", only as "writen") which would cause their data to be lost.
reply