Vincent Lefevre wrote: > With an uncompressed mbox file, using the Content-Length, it could be > faster, but there's still the problem with individual changes.
Have you run across Jamie Zawinski's rant against Content-Length? http://www.jwz.org/doc/content-length.html > > But let's say that all of the bodies were small less than 50k then I > > expect that converging them to a single mbox file would make them much > > faster than the individual files. > > 6.5 KB in average. With that many files it is going to take a long time. > > Also compressing the file reduces the amount of I/O needed to pull > > the data into memory. With today's fast cpus decompression is faster > > than disk I/O and reading a compressed file and decompressing it is > > usually faster in my experience. Every case is individually > > different however. If you run that experiment I would be interested > > in knowning the result. > > But recompressing would be very slow. If you are randomly accessing and modifying these old files then I suppose that is true. For people who want to archive messages read-only and never modify them it would be advantageous. Take a year's worth off the bottom and archive them every year in order to keep the Maildir working set size down. But if you are writing them periodically then that is something different. > I wonder whether there exists some specific FS that would make maildir > access very fast and whether using it on a disk image that could be > loop-mounted would be interesting. I have no idea. It would be interesting to benchmark xfs over ext4 for this purpose. But I am sure that everyone will suggest their favorite. Bob
signature.asc
Description: Digital signature
