Partitioning Scheme

[Daniel Hoffend]

I've created LVM slices for the following folders on my installation:

/var/lib/imap
/var/lib/dirsrv
/var/lib/mysql
/var/lib/amavis
/var/spool/imap
/var/spool/postfix
/var/log

Sounds complicated but it has it advantages. Some of them are outlined in the deployment guide on docs.kolab.org

The main reason is I can create a LVM snapshot of the Cyrus data an savely create backups without data being changed in the middle of the backup.

About MySQL usage: someone said that MySQL usage it's quite low, depending on your user size this won't be the case, cause *dav subsystem is heavily as cache, search and filter system. With mysql caching turned of, irony will not work at all, so keep this in mind when designing your partition layout.

Having a seperate spool postfix slice can help accepting mails when something filled up your disks pace

Amavis: so mail bombs won't crash your system and just blocks amavis

Logs: same for logs. Accidentally leaving debug on or something else filling up your log disk space should not kill your system.

In the end it all depends in your installation size. I would allocate 900gb for imap if you expect 50gb in the beginning. Make it 200gb and leave the rest free. With LVM+ext4 you can always increase the LVM slice and resize the file system, but you can't shrink it without rebuilding (backup, delete, create, restore)

Oh and btw in all cases, having some kind of disk space monitoring is a must have.

-- 
mfg
Daniel Hoffend

> Am 02.01.2014 um 23:32 schrieb Chloé Desoutter <chloe.desoutter at atasta.net>:
> 
> Le 02/01/2014 23:05, Brad Galbraith a écrit :
>> Thank you. Looks like relatime would be a good route.
>> 
>> Can you confirm a simple partition scheme as such? It's been many years since I've done this (hence my old school /boot) and I hate doing things twice.
>> 
>> / 6GB
>> /tmp 1GB
>> /var/spool/imap/  900GB with relatime mount option
> Nothing more needed. Backups are your best option for data safety. Partitioning won't ever save you.
> 
> Yours sincerely
>> 
>> Thanks again,
>> 
>> Brad
>> 
>> Chloé Desoutter wrote:
>>> Le 02/01/2014 22:43, Brad Galbraith a écrit :
>>>> *So something like this then?
>>>> 
>>>> / 6GB
>>>> /tmp 1GB
>>>> /var/spool/imap/  900GB
>>>> 
>>>> 
>>>> Don't add*
>>>> 
>>>> /var/lib/mysql/
>>>> /var/lib/imap/
>>>> 
>>>> I'll read up on relatime or noatime  but would you mind expanding on that a bit? The advantage with kolab?
>>> Basically, w/o relatime or noatime, each time a file will be accessed, the file's metadata (access time) will need to be written on disk. This adds a slight amount of I/O especially when dealing with big mailboxes (for example when indexing or performing a full text search). This and keeping atime consistent isn't useful for cyrus IMAP folders because all is handled with Cyrus' own metadata system.
>>> 
>>> The explanation here summarizes it well: http://linux.koolsolutions.com/2009/01/30/installing-linux-on-usb-part-4-noatime-and-relatime-mount-options/ 
>>> 
>>> I use relatime,nodiratime as my mount options for /var/spool/imap (because I'm unsure that relatime applies to directories).
>>> 
>>> Yours sincerely,
>>> 
>>> _______________________________________________
>>> users mailing list
>>> users at lists.kolab.org
>>> https://lists.kolab.org/mailman/listinfo/users
>> 
>> _______________________________________________
>> users mailing list
>> users at lists.kolab.org
>> https://lists.kolab.org/mailman/listinfo/users
> 
> 
> -- 
> Chloé Desoutter
> Atasta NET
> 
> <chloe_desoutter.vcf>
> _______________________________________________
> users mailing list
> users at lists.kolab.org
> https://lists.kolab.org/mailman/listinfo/users