On Mon, Jul 20, 2026 at 12:53 +0800, Kevin J. McCarthy wrote:
Commit f2eef427 seems to indicate adding the sort was for reducing
seek time.
Oh, it sorts by inode number to reduce seeking? Unix filesystems
traditionally put inodes on disk in a block, in numeric order -- but
this is apparently about reading file contents, not inodes. File
contents might end up in roughly the order of inode numbers, in a fresh
new filesystem, but that changes over time.
However, disk drivers sometimes sort a queue of disk commands by block
number, which does the same thing, and disk drives often optimize
internally, especially on read.
And there's ZFS, a completely different filesystem now popular on Unix
systems, where this hack may not apply.
And "solid state disks" don't seek.
And it's questionable for an application to assume anything about the
internal implementation of a filesystem. It's a violation of software
layering.
Programmers are notoriously bad at guessing where software spends its
time. The standard advice is to *measure* speed if you're concerned about it.
Applying that advice, I guess anyone tempted to remove this speed hack
should measure speed first, with and without the hack, in at least all
the cases above. And remember that disk drives and filesystems both
have cache. A lot of work...
