journaling fs and large mailbox format

[Alin-Adrian Anton]

Eric Anderson wrote:
> Alin-Adrian Anton wrote:
> 
>>
>>     I don't know if the mbox format can handle this, and I know 
>> Maildir cannot handle this on UFS2 standard install, no matter of 
>> soft-updates. (because it exhaustes the free nodes) So I currently 
>> have no solution for this stuff.
> 
> 
> I'm not sure how you came to this conclusion, or what the history is, 
> but I see no reason why UFS2 would have any adverse affects on maildir 
> format mail system.  You can set the number of inodes to be created to a 
> higher number when using newfs on the filesystem, so if you believe that 
> is an issue, you should be able to tweak it to your needs.  mbox starts 
> to break down on large mailboxes with many messages.  50mb may or may 
> not be in that range, but maildir is much better for performance.
> 

I run out of inodes with Maildir, and there were just a few hundred 
accounts. Outlook ppl tend to "leave their messages on server if they 
are not 7 days old" and this brings Christmas every day.

OK now i received some directions of how to tune it for Maildir, and 
there's also this link I received:

http://www.mostlygeek.com/node/11

> 
> A quick note - run the mail area on a RAID array, preferrably a RAID0+1 
> (or 10 depending on who you ask).  Disks are nearly always a bottleneck, 
> so if you can keep your random read/writes fast, the whole system will 
> feel snappy.

Defenately.

Also there is this:
http://www.dbmail.org/

something more appropiate to my principles, however I was told it's not 
so stable.

> 
> You might try posting this to freebsd-isp@, since many people there have 
> much larger installations running than this, and can probably provide 
> some good hints.
> 
> 

Thanks for the tip.

Mike Meyer wrote:
 > The solution isn't to avoid Maildir/mh - the solution is to tune the 
file system for the expected usage.

Well, I dislike throwing up my problems to a superior level, and act 
like it was brilliant. It was just running away from the issue, instead 
of dealing with it. More exactly, storage problems are database theory. 
Storing the mail is a classic database problem. Throwing this up to the 
filesystem level is not an elegant way of dealing with it, because now 
the filesystem must solve it, and this imposes new restrictions to the 
filesystem.

I agree, B-trees are for database index problems, and not only, however, 
just imagine what would happen if mySQL or PostgreSQL would throw away 
their database indexing/locking issue up to the filesystem level? It 
would be a total hoax, one would need separate filesystem tuning for 
mysql, one for postresql, one for mail, one for apache, etc.. This just 
brings headaches and unnecessarry restrictions to the partitioning schema.

This is why something like dbmail seems more appropiate in my opinion 
(conceptually).

 >Neither journaling nor soft updates would solve the problem of running
out of inodes. The only solution there is more inodes. XFS may be
flexible enough to deal with file systems that far from the norm - but
I wouldn't write a business plan based on it without checking first.

XFS fits incredibly well with Maildir, however this I did not test 
practically (i'd need Linux for that :) ). I think having XFS and maybe 
ReiserFS in BSD is a must (and obviously there must be reasons for being 
a must, one of them being a large scale Maildir situation), however it's 
just my opinion.

ZCB wrote:
 >From personal experience on a smaller system(~1000 accounts and
nearly all ways less than 45MB boxes) I would suggest avoiding mboxes
all together. Maildir is all ways the way to go. For cleaning stuff
out automatically and ect, maildir is much nicer as well.

Hm ok, thank's for the info.

 >Also is this vnodes or inodes? See the tuning man pages. For vnodes,
there are some sysctls.

Inodes. I'll try both tuning the FS and using dbmail, and see what happens.

Thank you all.

Yours Sincerely,
-- 
Alin-Adrian Anton
GPG keyID 0x183087BA (B129 E8F4 7B34 15A9 0785  2F7C 5823 ABA0 1830 87BA)
gpg --keyserver pgp.mit.edu --recv-keys 0x183087BA

"It is dangerous to be right when the government is wrong." - Voltaire