And then hiring a personal chef for that person. Sure, the food will taste better, but at what cost? At what cost?
(Actually watching defrag stopped being satisfying around the time that I got my first 50GB HDD. It took too damn long to watch, like a 2 year old playing Tetris in slow motion)
Well, with this new website, you can now enjoy defraging without having to suffer the consequences of a bad file system.
Maybe I should just defrag my SSD's these days. Sure they don't need it's but it's fast and bad for the drive, which gives it that same thrill of gambling with the integrity of my data. Of course I'd need to disable cloud backups to backblaze and local backups to a raid array, but if I try then I think I can still chase the thrill of the 'frag.
If you use a filesystem with checksums, you can also scrub it. The stakes are there: is my data bit rotted? Will the errors resist recovery? It also takes about the same time as the defrag, but again I don't know of any graphical tools.
xfs_fsr -vEven "worse", now I an translating some English text adventures into Spanish.
And by playing them OFC.
Today I have more fun doing actual projects (programming, writting, playing with teleco stuff) than badly simulating then in video games.
With DOS/Windows you simulated a life on games. With Linux, you made it real. Seriously. Slackware it's still a "game changer. You don't play Cyberpunk 2077 if you want, you can make it real life. I do that with the PocketCHIP, Gopher and text gaming/roguelikes/MUDs up into a mountain at night. Incredible experience.
Or better, listening to the ISS with a WebSDR and decoding SSTV images with QSSTV. That's the ultimate cyberpunk experience.
*edit: not entirely true: the Seagate MACH.2 drive series that has 2 separate head assemblies per drive. They're pretty expensive and hard to get ahold of.
In the rare circumstances when I was in need of actual defrag of a heavily polluted drive > 40Gb I opted to take a filesystem aware image with Norton/Symantec Ghost and just re-image it back. Worked fine and by the time of 100-200Gb drives there were a USB HDDs so I wouldn't even need to unscrew the PC case.
Great times!
I think I might have been able to get something in the local public university computer centre. It was the beginning of the internet (14.4 modems min to connect to the university, which was the only internet provider)
Great fun times!
Some PCs just last. A 2.4 GHz Core2 Quad I had, I think from 2008, is still going strong and can run most modern software just fine.
It's amazing how little progress there has been in last 13 years. In the nineties you had to upgrade every two years or so just to be able to run current software.
I think 2021 computer has a good chance of being still completely usable in 2040.
I'm currently building my next computer, and the difference again is just staggering. And that is not even factoring in that the next one has got 12-cores.
It is not that the progress hasn't been slow (I guess it has if you compare it to the pace of the past), but I think it has more to do with computers back then still being very capable.
You can still fire up some CAD software and do proper work on the Q6600. I mean, right until you want to listen to music or do some very light web browsing. Then it will suddenly become quite painful. The amount of waste in today is incomprehensible. No seriously, properly incomprehensible.
I recently set-up my old Q6600 as a station for CNC machinery, that thing flies with LinuxCNC on a small SSD. There's no issue running firefox and a music player at the same time (though I tend to not have other things running when milling something but more by cargo-cult than actual tests of the impact on the real-time behaviour needed for the CNC machine control). Some operations on Inkscape are of course slower than on more recent hardware but otherwise it's still very useable.
And of course you can surf the web. But even with 5GHz turbo it is still slower than a fast connection was in the late 90s (on 90s hardware and browser). And it has nothing to do with that progress hasn't advanced in that time (we are talking orders of magnitude).
Absolute garbage, and entirely representative of all other consumer class software.
I do think I could still manage on Q6600 with 16 GB RAM and an SSD. Might need to downscale VMs and browser tabs, but manageable in a pinch. Heck, in the early nineties I was happy to have an Amiga with 1 MB of RAM and that thing flew in comparison to C64. :-)
In reality though, the increase in performance was barely noticeable.
But I’d be interested in any real data anyway.
Most of the time however, my disk was probably only about 30% fragmented (if I recall correctly from Speed Disk). I was running DOS on a FAT file system where there was no swap file or anything that would cause massive fragmentation except deleting and installing programs, and maybe some temp files created by certain programs. The performance delta for me was barely noticeable on a 40MB Seagate IDE drive.
Why not?
$ virt-make-fs --type=msdos /usr/share/doc /var/tmp/disk.img
$ export file=/var/tmp/disk.img
$ nbdkit eval \
after_fork=' echo 0 > $tmpdir/read ' \
get_size=' stat -Lc %s $file ' \
pread='
diff=$(($4 - `cat $tmpdir/read`))
echo $4 > $tmpdir/read
if [ $diff -lt -10000 ] || [ $diff -gt 10000 ]; then
# simulate a seek
sleep 0.1
fi
dd if=$file skip=$4 count=$3 iflag=count_bytes,skip_bytes
'
$ sudo nbd-client localhost /dev/nbd0
$ sudo mount /dev/nbd0 /tmp/mnt
I would use process monitor from sysinternals to measure which files are loaded as the system boots. Then use jkdefrag/mydefrag to take said list and rebuild drive into different zones. Try to put small files that are used together in the same area of the disk. Put huge things like 'isos/vhds/acrivezips' etc near the end of the drive. Put small frequently used files near the front in used order if possible. Smash out any gaps if possible. This helps NTFS from creating more fragments. Defrag any files that 7zip unarchives immediately as it has a bad habit of creating highly fragmented files (contig from sysinternals). Try to put file index in its own 'area' as one reason it runs so badly is the drive fragmentation it causes to itself. It got so bad I would put the index on its own partition sometimes. Try to put files that fragment frequently in their own 'zone' as NTFS will tend to pick the next available gap to where the file is (not always).
That made a real noticeable difference in perceived speed.
These days with nvme and ssd I might just defrag the files themselves once a year if I feel like it. There is a difference but the perceived is pretty much not there anymore. The difference is there is a chain of sectors in the MFT that windows will have to traverse if you ask for something in the middle of a file. That is about the only thing you save with newer drives. ext4 has a similar issue. But it seems to be better about picking spots where it will not fragment. It will however fragment badly in low space conditions. Most filesystems will.
First thing the middle of the volume/partition is not the middle of the disk in any multi-partitioned disk, then NTFS $MFT is not (and never has been) in the middle of the partition, its location varies depending on the size of the volume/partiton but above a certain size, around 5/6 GB it is at a fixed offset, usually on LCN #786432 which - on a normal 8 KB/cluster NTFS volume - amounts to offset 6,291,456 sectors or 6,442,450,944 bytes, rarely the middle of the volume, unless its size is around 13 GB.
Seems to me the MFT was in the middle of volumes commonly in older versions, and lately much closer to the beginning of the volume.
Could have something to do with the feature of shrinking a volume which became more common, and you can now more often shrink an NTFS volume by more than half, which was often impossible in earlier years.
If you "think in hex" the address is in the PBR expressed in clusters (VCN) as "0xC0000" (at offset 0x30 or 48 dec you should find "00000C000000000"), which is a nice, round number.
Maybe you remember the "old" NTFS format (NT 3/4) where the mirror of the bootsector (aka $BootMirr, not the $MFT)was exactly in the middle of the volume, but since Windows 2000 this copy of the first sector of the PBR was moved in the "gray zone" at the end (inside the partition but outside the volume[1]).
As a side note (and JFYI) thanks to (from 7 onwards) NTFS resizing capabilities it is possible to "force" the $MFT to very early sectors, see this only seemingly unrelated thread here:
http://reboot.pro/index.php?showtopic=18022
[1] some info on the matter in this other, as well seemingly unrelated, thread:
This now makes me wonder whether the middle disk block (numerically) is equal "seek times" away from disk edges.
But yes these designs generally seemed to be much better than FAT under DOS or Windows at avoiding excessive fragmentation.
SSD drives don't need to be defragged.