Date: Wed, 24 Sep 2008 19:49:54 +0200 (CEST) From: Wojciech Puchar <wojtek@wojtek.tensor.gdynia.pl> To: Lowell Gilbert <freebsd-questions-local@be-well.ilk.org> Cc: Laszlo Nagy <gandalf@shopzeus.com>, freebsd-questions@freebsd.org Subject: Re: dovecot, maildir, UFS 2 performance Message-ID: <20080924194436.P65305@wojtek.tensor.gdynia.pl> In-Reply-To: <447i91bh1n.fsf@be-well.ilk.org> References: <48D95A19.8030700@shopzeus.com> <20080923235932.U55719@wojtek.tensor.gdynia.pl> <48D9E8C0.6020805@shopzeus.com> <447i91bh1n.fsf@be-well.ilk.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 2) keeping problems on one partition from raising trouble on another > partition. e.g., filesystem corruption in a home directory keeping > the root from being able to boot, or filling up a mail directory > keeping people from logging in. today we have live CDs. and - UFS doesn't get totally corrupted, just few files lost etc. files and directories that are not written for a long never get corrupted so you will always have kernel and /rescue anyway i said tradition - because very old unix filesystems (25 years ago.. or more) was different and sometimes got totally corrupted. Of course if hardware will fail, you can lose all filesystem. or all filesystems with multiple partitions. end effect is the same. > 3) fsck: Background fsck can't be done on the root filesystem, so if > you have a large root, that amounts to a substantial delay booting > after a crash. i STRONGLY advise all to add background_fsck="NO" to /etc/rc.conf because background fsck DO make problems > > 4) backups: dump(8) works on a filesystem basis, so organizing the > data for backup (with dump) means organizing according to > filesystem. The same applies to snapshots. you have to dump all anyway, and you have chflags nodump to mark directories and files that should not be backed up.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080924194436.P65305>