[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: the correct way to read a big directory? Mutt?

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.


  Nicolas George

Attachment: signature.asc
Description: Digital signature

Reply to: