This looks like Norton Utilities' Speed Disk. My 8-year-old self really thought that rearranging blocks to be sequential really made the disk faster.
In reality though, the increase in performance was barely noticeable.
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.