Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
The discussion has already moved on, but I just couldn't let this bit sit un-corrected.

The main reason for that is fragmentation; as free space approaches zero, the drive is usually forced to use whatever bits and pieces of free space remain to store files, which often results in severe fragmentation.

And that's nonsense. There's no meaningful amount of fragmentation on a Mac hard drive. The speed loss happens 99% because number of bytes per second is reduced, _and_ because more of the drive is used, average head movement is more. But _not_ because of fragmentation.
 
And that's nonsense. There's no meaningful amount of fragmentation on a Mac hard drive. The speed loss happens 99% because number of bytes per second is reduced, _and_ because more of the drive is used, average head movement is more. But _not_ because of fragmentation.
The bulk-read slowdown is due mostly to files on the inner tracks of the drive rather than the outer, that's of course true. The difference between speed at the outermost track and innermost track on a 3.5" drive is around 50%. (There's also a latency increase nobody mentioned, since the head will on average be moving around more on the surface of the platter.) I don't think my comments about fragmentation are nonsense, though.

On a disk with no defragmentation, the constant grinding you get has everything to do with fragmentation and nothing to do with read speed. In fact, a bulk read or write of an unfragmented large file will barely involve any head seeks, so won't make much drive noise at all.

And while it's 100% true that newer versions of OSX (since they implemented auto-defrag and hot-file adaptive clustering in I believe 10.3) is drastically less prone to fragmentation than earlier versions of the OS (and Windows, although 7 does somewhat simpler auto-defragmentation on a fixed schedule by default), it is not immune to fragmentation. That's very rarely an issue in most real-world use cases, but it becomes more likely to be one the less free space you have available.

OSX's automatic defragmentation is still, to my knowledge, limited to files under 20MB--it leaves bigger files alone, although HFS+ and newer OSX versions also do a lot of other things to try and minimize fragmentation. It does not, to my knowledge, defragment free space.

Again, though, if the disk is almost full (by which I mean 99+%), the fact that OSX doesn't defragment large files is what can result in issues; since the tiny amount of free space remaining is probably very fragmented, if you write a larger file, it will end up badly fragmented, and the OS isn't going to try and defragment it automatically.

99.9% of Mac users have no need to defragment (this guy did an interesting analysis a few years ago), but there are situations--particularly if the disk is run almost full for a while, and if you work with big files--where fragmentation does become an issue, at which point the fragmentation slowdown is a much bigger issue than the ~50% speed decrease.

It's an old article, but that's how Apple itself explains it: https://support.apple.com/kb/HT1375

If your disks are almost full, and you often modify or create large files (such as editing video[...]), there's a chance the disks could be fragmented. In this case, you might benefit from defragmentation, which can be performed with some third-party disk utilities.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.