Now HNers here don't even question the soundness of this software and just assume it works as it was suspiciously built in 4 days.
One side-effect of the AI mania is that developers have lost the ability to reason around the verification stage of vibe coded software.
Oh dear.
> Fragmentation and extent allocation were adding measurable variance, even on NVMe,
Why exactly would there be a measurable variance on NVMe? I understand there could be some impact on magnetic hard drives. This sounds like some sort of coincidence due to other factors and that this defragmentation won’t achieve much (except for wearing out your SSD even faster in certain cases).
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
If you're at the point where you're optimizing for this, you've got some really high performance requirements though. And you'll have to do your own testing, because rules of thumb won't do.
I suspect the noise is caused by the power supply emitting a tiny bit of 'coil whine' when put under more load
The "Fast, Cheap, or Good... choose any two..." joke is very real. =3
Just as an idea for a feature your defragmenter could have.
(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.
I love it!
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.
Defragmenting my drives manually is one of those things like closing apps on my phone I am not using. Everyone says there is no need to do it. It might even be slightly worse overall. I even have enough self control to avoid doing it and have for years...
But deep down in my heart, I truly FEEL like if I did it would improve things... somehow.
I too am nearly certain that the positive benefits are approaching nil, but I still feel it should be helpful.
I'd be curious to know the reqson why she would care on her own phone and why it would be an issue on someone else's phone?
Despite this, many of my relatives have somehow learned this habit of opening the switcher and closing all apps when they are done with them.
But the switcher shows every app ever opened and tries to pretend these apps aren't being closed. Right now for instance, i just checked and as best i can tell, the last 3 were open. going back any further and i could tell the app had to reload. but i can scroll to the left back forever. the one on the furthest left i easily haven't opened for months
Otherwise the claimed defragmentation here is not actually resulting in sequential data.