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
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
