| From: | "Gregory Maxwell" <gmaxwell(at)gmail(dot)com> |
|---|---|
| To: | "mark(at)mark(dot)mielke(dot)cc" <mark(at)mark(dot)mielke(dot)cc> |
| Cc: | "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Gurjeet Singh" <singh(dot)gurjeet(at)gmail(dot)com>, "PGSQL Hackers" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: New CRC algorithm: Slicing by 8 |
| Date: | 2006-10-24 17:56:45 |
| Message-ID: | e692861c0610241056o3fa8dc1x5c1afea4d88ef297@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 10/24/06, mark(at)mark(dot)mielke(dot)cc <mark(at)mark(dot)mielke(dot)cc> wrote:
> I wasn't aware that a system could protect against this. :-)
>
> I write 8 Kbytes - how can I guarantee that the underlying disk writes
> all 8 Kbytes before it loses power? And why isn't the CRC a valid means
> of dealing with this? :-)
[snip]
A file system with an apropreiate transaction method could do this..
In *theory* reiser4 write()s are atomic. No one has verified, however,
that there is no torn page risk introduced in some other part of the
kernel.
I'm not aware of any other system which can guaranteed the atomicity
of 8k writes.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joshua D. Drake | 2006-10-24 18:07:28 | Re: Incorrect behavior with CE and ORDER BY |
| Previous Message | Alvaro Herrera | 2006-10-24 17:51:47 | Re: New CRC algorithm: Slicing by 8 |