Le quintidi 5 floréal, an CCXXIII, Vincent Lefevre a écrit :
> Mutt uses a
> different order, and after a look at its mh.c source file, I can see
> that it sorts the files by inode number (see maildir_delayed_parsing
> function). IMHO, this is a good choice because, specially in big
> directories, doing that may lead to contiguous files on the disk,
> and I think that it is the reason why Mutt is much faster.
This is the corresponding entry in Mutt's ChangeLog:
2005-01-27 18:45:37 Florian Weimer <fw@deneb.enyo.de> (roessler)
* mh.c, configure.in: Read files in maildir folders in inode
order; this seems to reduce seek overhead on Linux. Enabled by
default; to disable, run configure with --disable-inodesort.
(By way of Mario d'Itri.)
Mario looks like a typo for Marco; Marco d'Itri is a known name in the Linux
community, although I do not quite remember for what (sorry if you happen to
read that).
Reading the mailing-lists archives around that date may be interesting.
> Now I wonder whether the use of the hash by ext3 is a good idea...
>
> Alternatively, I suppose that a SSD disk could improve things.
Well, filesystems can not be optimized for every use. Having myriads of
small files has always been a bad idea anyway, it trashes the inode and
dentries cache, it costs extra disk bandwidth (because you can not read half
a sector at the end of the file) and latency (because of all the seeks, even
when reading in order, it will be more fragmented than a single file), etc.
Of course, nowadays, huge RAM and SSD will mitigate the issue.
It is a tragedy that a standard, robust and efficient format for mailboxes
was never designed and adopted.
Regards,
--
Nicolas George
Attachment:
signature.asc
Description: Digital signature