Re: kmail corrupts emails [solved]

[Randy Kramer <rhkramer@gmail.com>]

On Tuesday 27 September 2005 09:27 am, Derek Broughton wrote:
> Randy Kramer wrote:
> > I suppose maildir will be OK (and maybe even better) for my inbox, which
> > I generally keep "trimmed" (not too many emails).
> >
> > I don't think I want to do that for my mail folders which often have a
> > lot (thousands) of archived emails (usually short).
> >
> > Is it the general consensus that mbox is more subject to corruption than
> > maildir?
>
> By definition.
>
> Why do you think Maildir would perform worse for folders with thousands of
> emails?  Everything I've read suggests it will perform better - and more
> reliably.

Thanks for asking!

I may have to exorcise some old MS Dos/Windows demons from my thinking.

First a quick (but dumb, I should look it up) question.  Does Linux do the 
thing that Dos/Windows does (used to do?) of each file requiring a minimum 
space (one cluster?), or does it vary by filesystem?  

Attempting to answer my own question:  Presumably (V)FAT(16,32) must be the 
same as MS for compatibility.  I don't have any idea, though, about ext2 and 
ext3, and I'm guessing (and may have read) that one of the ways Reiser's 
achieves its greater efficiency for small files is by not doing that?

Then, I can remember (again, back in my dos/Windows days) two problems that I 
may mix up a little bit.  I guess the first was the limitation on the number 
of files on a disk based on the size of the (primary?) FAT, which was, iirc, 
overcome by allowing secondary or virtual FATs (or something along those 
lines).  I'm sure that's not a problem in Linux.

The 2nd problem, referenced above--I did run into applications where the 
number of files in a directory was so large that the access time for a file 
became unacceptable because (I guess) of the time required to search the FAT?  

(Aside: I can't remember when that number became a problem in dos/Windows, but 
I'm sure it was before 10's of thousands of files in a directory.)   

I don't know if Linux can run into the same problem.  It seems that an indexed 
file (e.g., mbox with index) is an alternative to that, ahh, but I guess only 
if the index can be searched very efficiently.  

How is a search for a file name done in Linux--is it a linear type thing? 
(Without being very conversant in big O notation, I'm trying to ask if it's 
proportional to the number of entries (file names) in the directory (would 
that be O[n]?), or does it do something more clever (would that be O[1}?).  
Or, again, does it depend on the file system, (and maybe Reiser's has that 
(potential) problem licked?)

Finally (for now ;-), without fully understanding inodes, I guess I'd be 
worried about running out (or needing to allocate an excessive number in 
advance) to allow for super large quantities of files.

Or, I guess one might say all of these problems might be controlled by proper 
administration/tuning of the system, which might include picking an 
appropriate type of filesystem for the requirements.  Still, I was hoping to 
get a little more insight by mentioning these points for discussion.

Thanks!
Randy Kramer