CRCs (was: beta testing version) - Mailing list pgsql-hackers

From ncm@zembu.com (Nathan Myers)
Subject CRCs (was: beta testing version)
Date
Msg-id 20001206111856.R30335@store.zembu.com
Whole thread Raw
In response to AW: beta testing version  (Zeugswetter Andreas SB <ZeugswetterA@Wien.Spardat.at>)
List pgsql-hackers
On Wed, Dec 06, 2000 at 12:29:00PM +0100, Zeugswetter Andreas SB wrote:
> 
> > Why should we do this? I'm not going to replay parts individually,
> > I'm going to write entire pages to OS cache and than apply changes
> > to them. Recovery is considered as succeeded after server is ensured
> > that all applyed changes are on the disk. In the case of crash
> > during recovery we'll replay entire game.
>
> Yes, but there would need to be a way to verify the last page or
> record from txlog when running on crap hardware. The point was, that
> crap hardware writes our 8k pages in any order (e.g. 512 bytes from
> the end, then 512 bytes from front ...), and does not even notice,
> that it only wrote part of one such 512 byte block when reading it
> back after a crash. But, I actually doubt that this is true for all
> but the most crappy hardware.

By this standard all hardware is crap.  The behavior Andreas describes 
as "crappy" is the normal behavior of almost all drives in production, 
including the ones in your machine.

Furthermore, OSes re-order "atomic" writes into file systems (i.e.  
not raw partitions) to match partition block order, which often doesn't 
match the file block order.  Hence, the OSes are "crappy" too.

Wishful thinking is a poor substitute for real atomicity.  Block
CRCs can at least verify complete writes to reasonable confidence, 
if not ensure them.

Nathan Myers
ncm



pgsql-hackers by date:

Previous
From: Bruce Guenter
Date:
Subject: Re: AW: beta testing version
Next
From: "Mikheev, Vadim"
Date:
Subject: RE: Logging for sequences