Re: [vchkpw] OT - Preferred File Systems
Ed McLain wrote: snip As for recoveries after a hardware failure, I've only had to do 3 or 4. On one of them we had a buggy version of xfs_repair, and that caused some weirdness, but we had done a full dd before the restore to a secondary disk.. After upgrading xfs_repair we got back everything with no corruption that we could find.. Now, that's not to say that a man page didn't have null's in it, but everything we wanted was there and in tact. snip Man pages? You had existing files corrupted? Now that is something I have not had with ext3. As for XFS, I did lose one filesystem but I cannot pin it down to XFS code with certainty because that happened after a crash although I have not lost any ext3 filesystem due to a crash yet. In any case, my previous mail was about files that were created just prior to a crash or a power cut, not existing files. Existing files should not get corrupted. If a filesystem cannot guarantee integrity of existing files both in a data and metadata sense, then I'd say that is a candidate for 'untouchable'. When you are dealing with a mail queue, as the OP was asking about, you do want data integrity because once the mail has been queued, the sending side will deleted its copy as you have now assumed responsibility for delivery. This really means that only filesystems that do full journaling can meet such a criteria. If you do not mind losing whatever was very recently queued in the event of a crash/power cut, then go for XFS. !DSPAM:476d1d36310541813613882!
Re: [vchkpw] [OT] IMAP Servers: Dovecot or Binc?
On Fri, 2007-12-21 at 13:25 -0700, Remo Mattei wrote:
yes I did any other suggestion?
None unfortunately. Though I have done some testing by removing the
quota of some users with the command
vmoduser -q [EMAIL PROTECTED]
and I have not been able to fault it. However if the quota is set to 0
(zero) there is a problem as the quota is at 100% immediately. I thought
zero was the default for no quota, but i havnt checked.
Shane
Thanks
Shane Chrisp wrote:
I had to disable that since some of the people with no quota set were
getting errors saying user is over quota and bounced messages. Any
suggestions on that?
remo
Did you have this option set?
plugin {
quota = maildir
}
All of my users have a quota set so I will have to try taking a quota off
someone to see what happens for me.
Shane Chrisp wrote:
On Fri, 2007-12-21 at 15:08 +0900, Shane Chrisp wrote:
Additionally if you want to run the check_quota plugin in squirrelmail
you will need to have
protocol imap {
...
mail_plugins = imap_quota quota
in your dovecot.conf
Shane
On Fri, 2007-12-21 at 01:02 -0500, Jeff Koch wrote:
Shane - where do you set the IMAP server option?
Run the config/conf.pl and choose option 2 (Server Settings)
then option 8 (server software).
Also if you plan on moving to a native dovecot style system, you need
to
get rid of the fullstops from the front of the .Sent, .Trash
directories
etc in squirrelmail I just found out.
Shane
Shane Chrisp
2000 Computers Networks Pty Ltd
Suite 6, 49 Hay St,
Subiaco, W.A. 6008, Australia.
P +618 9382 1399 F +618 9382 1720
!DSPAM:476d389b310544318113222!
Re: [vchkpw] OT - Preferred File Systems
On 12/22/07, Christopher Chan [EMAIL PROTECTED] wrote: snip I'd say XFS. But with the restriction you have battery-backed caches and redundant PSUs. XFS is so fast cause of it's caching mechanism. A power failure without battery-backed caches or redundant PSU will make you cry. And after you cry chances are very big you'll cry a lot more due to corruption. Patrick !DSPAM:476d693a310541648582167!
[vchkpw] OT - Preferred File Systems - I-RAM Drive
By the way, to give you an idea of the speed of the i-ram drive with the XFS file system we tar-zipped the entire /usr directory into an 811MB archive. It took 54 seconds to untar-unzip it on a 4GB I-Ram drive and 141 seconds on a Seagate 750 GB SATA drive with the ext3 filesystem in the same machine. The CPU is a Core-Duo 6400 with 4GB RAM. Straight file copies are even faster. Duplicating the same 811MB archive on the I-Ram took 13 seconds on the I-Ram drive and 43 seconds on the Seagate. My plan is to use the I-RAM for the following directories; var/qmail/queue var/qmail/simscan var/log maybe /tmp let me know if you guys think of any other directories that would benefit from the speedup. Also, since the i-ram's battery backup only lasts a few hours we added some startup scripts to rc.local that try mounting the i-ram and then test for the existence of some key files. If they don't exist or the i-ram can't be mounted we then we assume the RAM got erased and use parted to re-create the partitions and mkfs to add the xfs filesystem. Then we mount the i-ram drive and copy over and untar the directories that we backed up upon shutdown (and also backup every few hours). I think this approach should substantially speedup the mailserver and allow it to handle greater capacity. At 09:20 AM 12/22/2007, you wrote: Ed McLain wrote: snip As for recoveries after a hardware failure, I've only had to do 3 or 4. On one of them we had a buggy version of xfs_repair, and that caused some weirdness, but we had done a full dd before the restore to a secondary disk.. After upgrading xfs_repair we got back everything with no corruption that we could find.. Now, that's not to say that a man page didn't have null's in it, but everything we wanted was there and in tact. snip Man pages? You had existing files corrupted? Now that is something I have not had with ext3. As for XFS, I did lose one filesystem but I cannot pin it down to XFS code with certainty because that happened after a crash although I have not lost any ext3 filesystem due to a crash yet. In any case, my previous mail was about files that were created just prior to a crash or a power cut, not existing files. Existing files should not get corrupted. If a filesystem cannot guarantee integrity of existing files both in a data and metadata sense, then I'd say that is a candidate for 'untouchable'. When you are dealing with a mail queue, as the OP was asking about, you do want data integrity because once the mail has been queued, the sending side will deleted its copy as you have now assumed responsibility for delivery. This really means that only filesystems that do full journaling can meet such a criteria. If you do not mind losing whatever was very recently queued in the event of a crash/power cut, then go for XFS. Best Regards, Jeff Koch, Intersessions !DSPAM:476d7f49310544027043058!
Re: [vchkpw] OT - Preferred File Systems - I-RAM Drive
Jeff Koch wrote: By the way, to give you an idea of the speed of the i-ram drive with the XFS file system we tar-zipped the entire /usr directory into an 811MB archive. It took 54 seconds to untar-unzip it on a 4GB I-Ram drive and 141 seconds on a Seagate 750 GB SATA drive with the ext3 filesystem in the same machine. The CPU is a Core-Duo 6400 with 4GB RAM. ...how about apples to apples? Like when time it takes with the i-ram when it is formatted with xfs and when it is formatted with ext3? Straight file copies are even faster. Duplicating the same 811MB archive on the I-Ram took 13 seconds on the I-Ram drive and 43 seconds on the Seagate. My plan is to use the I-RAM for the following directories; var/qmail/queue var/qmail/simscan var/log Don't you want a more permanent record of logs? maybe /tmp let me know if you guys think of any other directories that would benefit from the speedup. Also, since the i-ram's battery backup only lasts a few hours we added some startup scripts to rc.local that try mounting the i-ram and then test for the existence of some key files. If they don't exist or the i-ram can't be mounted we then we assume the RAM got erased and use parted to re-create the partitions and mkfs to add the xfs filesystem. Then we mount the i-ram drive and copy over and untar the directories that we backed up upon shutdown (and also backup every few hours). That is assuming a complete power loss. The battery backup does not come into play if the server is turned off but still connected to the mains. The I-RAM will draw from power so long as the power supply is connected and not switched off. !DSPAM:476e0ebd310543618740901!
Re: [vchkpw] OT - Preferred File Systems
Patrick Ale wrote: On 12/22/07, Christopher Chan [EMAIL PROTECTED] wrote: snip I'd say XFS. But with the restriction you have battery-backed caches and redundant PSUs. XFS is so fast cause of it's caching mechanism. A power failure without battery-backed caches or redundant PSU will make you cry. And after you cry chances are very big you'll cry a lot more due to corruption. I think you meant having a UPS system. The I-RAM is a DRAM media drive and as such it has zero caches and we want to protect against the contents in main system RAM not making it. !DSPAM:476e0fa6310541573590211!
