Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 3B41A64FCFA for ; Mon, 8 Sep 2008 11:48:32 -0300 (ADT) Received: from postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 34893-09 for ; Mon, 8 Sep 2008 11:48:23 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-gx0-f17.google.com (mail-gx0-f17.google.com [209.85.217.17]) by postgresql.org (Postfix) with ESMTP id A106C64FCEC for ; Mon, 8 Sep 2008 11:48:22 -0300 (ADT) Received: by gxk10 with SMTP id 10so7915424gxk.19 for ; Mon, 08 Sep 2008 07:48:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=fqrvT4FvjUiAgtRcyvWeU3+TycekwGLPdHUOrYDjaZE=; b=TtYaCxVOJCscL2igZ4FsYQSrTt5/GJELJBpkXKJ4X1l81xPnMx37GmJ6JNHBdubxjL 3eN3HqY4mIQY44vXZf9vfv5Q+d2FWhcDBik1Al0G0JKEU1fnJWlVieQigo5vvpPtMXja x8rsOimU77CbNZLvkLkLzvOE5uCmZRRgQRmCk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=XwsFVgdEBuCrjLXSEmrGUXXyb5dd7/twqqQ9smbqvceE6ul6E//ahK0J/tjw3QiaYD KRfX3yCIeWIRUjL4Eq9q/13nXOyu3511FGNVPfOwIrSOWSA6rt2q4Khax2KG74JyA1ce 00ors/BLL7qNNcse52dUYVhnmw2Ik5Q3DtpHc= Received: by 10.115.22.1 with SMTP id z1mr12453043wai.99.1220885301095; Mon, 08 Sep 2008 07:48:21 -0700 (PDT) Received: by 10.114.120.19 with HTTP; Mon, 8 Sep 2008 07:48:21 -0700 (PDT) Message-ID: Date: Mon, 8 Sep 2008 10:48:21 -0400 From: "Nikolas Everett" To: "Gregory Stark" Subject: Re: SAN and full_page_writes Cc: "Bruce Momjian" , pgsql-performance@postgresql.org In-Reply-To: <87myii4t9o.fsf@oxford.xeocode.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_57280_22044613.1220885301091" References: <200809061946.m86JkeS01341@momjian.us> <87myii4t9o.fsf@oxford.xeocode.com> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.001 tagged_above=0 required=5 tests=HTML_MESSAGE=0.001 X-Spam-Level: X-Archive-Number: 200809/85 X-Sequence-Number: 31398 ------=_Part_57280_22044613.1220885301091 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Sorry about that. I was having tunnel vision and pulled out the part that applied to me. I also figured that the OS and file system information was superfluous but on second look it may not be. This bit: To satisfy the Durability requirement, all write operations must write through any OS cache to stable storage before they are reported as complete or otherwise made visible. Write-back caching behavior is prohibited, and data from failed writes must not appear in an OS cache. To satisfy the Serialization requirements, any OS cache must be fully coherent with the underlying storage. For instance, each write must invalidate any OS-cached copies of the data to be overwritten, on any and all hosts, prior to commitment. Multiple hosts may access the same storage concurrently under shared-disk clustering, such as that implemented by Oracle RAC and/or ASM. Sounds kind of scary. I think postgres forces the underlying OS and file system to do that stuff (sans the mutli-host magic) using fsync. Is that right? It does look like there are some gotchas with NFS. On Mon, Sep 8, 2008 at 10:16 AM, Gregory Stark wrote: > > "Nikolas Everett" writes: > > > Thanks for pointing that out Bruce. > > > > NetApp has a 6 page PDF about NetApp and databases. On page 4: > > Skimming through this I think all 6 pages are critical. The sentence you > quote > out of context pertains specifically to the NAS internal organization. > > The previous pages discuss limitations of OSes, filesystems and especially > NFS > clients which you may have to be concerned with as well. > > -- > Gregory Stark > EnterpriseDB http://www.enterprisedb.com > Ask me about EnterpriseDB's Slony Replication support! > ------=_Part_57280_22044613.1220885301091 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Sorry about that.  I was having tunnel vision and pulled out the part that applied to me.  I also figured that the OS and file system information was superfluous but on second look it may not be.  This bit:

To satisfy the Durability requirement, all write operations must write through any OS
cache to stable storage before they are reported as complete or otherwise made visible.
Write-back caching behavior is prohibited, and data from failed writes must not appear in
an OS cache.
To satisfy the Serialization requirements, any OS cache must be fully coherent with the
underlying storage. For instance, each write must invalidate any OS-cached copies of
the data to be overwritten, on any and all hosts, prior to commitment. Multiple hosts may
access the same storage concurrently under shared-disk clustering, such as that
implemented by Oracle RAC and/or ASM.
Sounds kind of scary.  I think postgres forces the underlying OS and file system to do that stuff (sans the mutli-host magic) using fsync.  Is that right?

It does look like there are some gotchas with NFS.

On Mon, Sep 8, 2008 at 10:16 AM, Gregory Stark <stark@enterprisedb.com> wrote:

"Nikolas Everett" <nik9000@gmail.com> writes:

> Thanks for pointing that out Bruce.
>
> NetApp has a 6 page PDF about NetApp and databases.  On page 4:

Skimming through this I think all 6 pages are critical. The sentence you quote
out of context pertains specifically to the NAS internal organization.

The previous pages discuss limitations of OSes, filesystems and especially NFS
clients which you may have to be concerned with as well.

--
 Gregory Stark
 EnterpriseDB          http://www.enterprisedb.com
 Ask me about EnterpriseDB's Slony Replication support!

------=_Part_57280_22044613.1220885301091--