Re: [PATCH v2] Simplify maildir_delayed_parsing().

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...