From: | Marco Colombo <marco(at)esi(dot)it> |
---|---|
To: | Alex Satrapa <alex(at)lintelsys(dot)com(dot)au> |
Cc: | "Pgsql (E-mail)" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: disaster recovery |
Date: | 2003-11-28 10:26:20 |
Message-ID: | Pine.LNX.4.44.0311281114320.25502-100000@Megathlon.ESI |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Fri, 28 Nov 2003, Alex Satrapa wrote:
[...]
> I have to admit that in none of those cases would synchronous vs
> asynchronous, journalling vs non-journalling or *any* file system
> decision have made the slightest jot of a difference to the integrity of
> my data.
>
> I've yet to experience a CPU failure (touch wood!).
I have. I have seen memory failures, too. Bits getting flipped at random.
CPUs going mad. Video cards whose text buffer gets overwritten by
"something"... all were HW failures. There's little the SW can do when
the HW fails, just report that, if it gets any chance.
Your data is already (potentially) lost when that happens. Reliably
saving the content of a memory-corrupted buffer to disk will just cause
_more_ damage to your data. That's expecially true when the "data" is
filesystem metadata. Horror stories. I still remember the day when
/bin/chmod became of type ? and size +4GB on my home PC (that was
Linux 0.98 on a 100MB HD - with a buggy IDE chipset).
.TM.
--
____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/ Colombo(at)ESI(dot)it
From | Date | Subject | |
---|---|---|---|
Next Message | omkar prabhu | 2003-11-28 11:19:00 | help transfer ring blobs using perl |
Previous Message | Marco Colombo | 2003-11-28 10:12:27 | Re: disaster recovery |