Re: SAN and full_page_writes

From: "Nikolas Everett" <nik9000(at)gmail(dot)com>
To: "Bruce Momjian" <bruce(at)momjian(dot)us>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: SAN and full_page_writes
Date: 2008-09-08 14:02:27
Message-ID: d4e11e980809080702i629187bbqab5dd70581ee8057@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Thanks for pointing that out Bruce.

NetApp has a 6 page PDF about NetApp and databases. On page 4:

As discussed above, reads and writes are unconditionally atomic to 64 KB.
While reads or writes
may fail for a number of reasons (out of space, permissions, etc.), the
failure is always atomic to
64 KB. All possible error conditions are fully evaluated prior to committing
any updates or
returning any data to the database.

From the sound of it, I can turn of full_page_writes.

This document can be found at http://www.netapp.com/us/ by searching for
hosting databases.

Thanks,

--Nik

On Sat, Sep 6, 2008 at 3:46 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:

> Nikolas Everett wrote:
> > I seem to have answered my own question. I'm sending the answer to the
> list
> > in case someone else has the same question one day.
> >
> > According to the NetApp documentation, it does protect me from partial
> page
> > writes. Thus, full_page_writes = off.
>
> Just for clarification, the NetApp must guarantee that the entire 8k
> gets to disk, not just one of the 512-byte blocks that disks use
> internally.
>
> --
> Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
> EnterpriseDB http://enterprisedb.com
>
> + If your life is a hard drive, Christ can be your backup. +
>

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Gregory Stark 2008-09-08 14:16:51 Re: SAN and full_page_writes
Previous Message Rainer Mager 2008-09-08 03:54:04 Re: indexing for distinct search in timestamp based table