Hacker News

I feel so seen right now. My partner complains about me closing apps on my phone consistently. I also have to hold myself back from defragging and continually cleaning up my storage drives.

I too am nearly certain that the positive benefits are approaching nil, but I still feel it should be helpful.

only HDD drives I use are in a ZFS pool which has a very usable fragmentation value from zpool.

Except for some backups, all of my machines use solid state storage so I don't think there is a point for most people, is there?

Be in a very quiet room and I can still hear my SSD.

I suspect the noise is caused by the power supply emitting a tiny bit of 'coil whine' when put under more load

SSD still have slower reads when the data isn't sequential. Not slow enough to matter, especially with extents meaning the data is probably in a handful of locations, not 10000, but it's absolutely measurable if your blocks are small enough (<1MB typically, though disk benchmarks usually use 64KB random reads and sometimes 4KB).

>defragmentation won’t achieve much

Indeed, most Linux setups supporting trim, already defer these operations to a weekly schedule to reduce wear, and most fs will optimize in 10MB or 25MB chunks given unlike HDD... the SSD seeks are nearly constant time. Logging fs like f2fs, are content aware so will auto re-locate hot and cold (rarely modified) file types, and despite the log-structure... on an SSD performance losses are often surprisingly negligible.

Most modern NVMe with dram cache and SLC buffer areas also defer committing pages to low-endurance flash areas. And most kernel tweakers will set swapiness to 1 on SSD/NVMe machines to try to keep stuff buffered in dram as long as reasonably possible. It is a space-time tradeoff that can boost a desktop machine performance especially with preload daemon active.

If people want ludicrous speed... than just run ext4 with a separate 128GB journal NVMe drive on a split PCIe x4 bus.

Defrag on most modern drives usually just fills these buffer areas full, and things grind to the slowest i/o choke point. =3

> Also this is a side thought; but I wonder if AWS AMIs and EBS volumes will boot faster if also organized sequentially.

Probably a measurable, but small, difference. I would expect it's not worth the effort unless you're spending a lot of time booting, and even then, there's probably better things to work on in the boot process, such as reducing the amount of things that run or reducing the size of them.

Page caches are nice, but you would see meaningful reduction in load times for the OS and applications by getting data in order on spinning disks. Especially games that used most of your ram and loaded reasonably large level files.

fat seemed particularly prone to spreading files into very small chunks across the disk surface; it's not so big of a deal when fragmented files are made up of large contiguous chunks.