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

Re: kmail corrupts emails [solved]



Randy Kramer wrote:

> On Tuesday 27 September 2005 09:27 am, Derek Broughton wrote:
>>
>> 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.
> 
> 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?

It varies decidedly between the different filesystems.
> 
> Attempting to answer my own question:  Presumably (V)FAT(16,32) must be
> the same as MS for compatibility.  

Yes.

> I don't have any idea, though, about ext2 and ext3, 

Ext3 is just ext2 with journalling.  You can even mount an ext3 partition as
ext2.  That said, I've never pried into the internals but it does store
files more efficiently than a FAT system.

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

Not in a long time.
> 
> 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?
>
> I don't know if Linux can run into the same problem.  

Again, I haven't looked into the internals but by all reports it isn't an
issue where the number of files is on the order of "thousands".  Actually,
since I _do_ know how FAT works, I don't see why a properly written
application should have that much difficulty finding a file in a FAT
directory either.
 
> 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.

And only if you can guarantee that the index is in sync with the file - per
Reinhold's email.
 -- 
derek



Reply to: