On 08/12/2010 01:55 AM, Fajar Priyanto wrote:
> Hi guys,
> I don't mean to incite debate or something, just want to share
> experience and a little curiosity.
>
> Back long time ago, we have an old file MS W2K (NTFS) server where due
> no admin was available to manage it, the server would get power off
> when the office closed, and auto power on again in the morning. That
> thing happened for years and it was fine ^^
>
> Recently, I setup a Centos 5.5 file server with ext3 and got power
> blackout twice and I notice the filesystem got corrupted and also bad
> sectors.
>
> Is it just pure random luck, software or hardware issue?
> What's your experience?
>
I would say 'luck'. No common system is normally 100% safe against 'pull
the plug' shutdowns. Also, it matters how much disk I/O the system is
doing. A system that is idle will tolerate 'pull the plug' better than
one actually doing something. Additionally, powering up and powering
down is the hardest thing you can do to the *hardware*. Servers should
be let run 7/24 - they last longer. Finally, if power failures are
taking the machine down, buy a UPS and connect the monitoring cable. I
like APC UPSs and apcupsd for monitoring it and automatically shutting
the system if needed.
You can improve ext3's resistance to corruption quite a bit if you use
the 'journal=data,barrier=1' mount options. Barriers is actually one of
the few cases where software RAID or LVM hurts you - they don't honor
barriers (at least not in CentOS/RHEL - newer kernels have improved this
somewhat). If you are using a hardware RAID card with onboard cache -
make **SURE** it has battery backup installed, too, or else turn off the
cache completely. If you are using LVM/software RAID you will also need
to turn off the hard drives *own* write caches as well. And yes - you
are going to take some serious performance hits from doing all this. You
are trading performance for reliability in the face of power failures.
And use ext4 instead of ext3 (ext4 adds journal checksumming) if you can.
Here is an article discussing making linux disk I/O safer:
http://www.linux-mag.com/id/7773/
--
Benjamin Franz
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
