Received: from maia.hub.org (unknown [200.46.204.251])
	by mail.postgresql.org (Postfix) with ESMTP id 3C5E11337B6D
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Fri, 22 Oct 2010 13:36:37 -0300 (ADT)
Received: from mail.postgresql.org ([200.46.204.86])
	by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia,
	port 10024) with ESMTP id 82648-04
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Fri, 22 Oct 2010 16:36:29 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from shrek.krogh.cc (2605ds1-ynoe.0.fullrate.dk [90.184.12.24])
	by mail.postgresql.org (Postfix) with ESMTP id D45D61335B36
	for <pgsql-performance@postgresql.org>;
	Fri, 22 Oct 2010 13:36:28 -0300 (ADT)
Received: from localhost (localhost [127.0.0.1])
	by shrek.krogh.cc (Postfix) with ESMTP id E6505D94D6;
	Fri, 22 Oct 2010 18:36:26 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at shrek.krogh.cc
Received: from shrek.krogh.cc ([127.0.0.1])
	by localhost (shrek.krogh.cc [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id FU2grQJkikBJ; Fri, 22 Oct 2010 18:36:23 +0200 (CEST)
Received: from [90.184.13.151] (2605ds1-ynoe.2.fullrate.dk [90.184.13.151])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: jesper@krogh.cc)
	by shrek.krogh.cc (Postfix) with ESMTPSA id 59AC1B149C;
	Fri, 22 Oct 2010 18:36:23 +0200 (CEST)
Message-ID: <4CC1BD86.8070006@krogh.cc>
Date: Fri, 22 Oct 2010 18:36:22 +0200
From: Jesper Krogh <jesper@krogh.cc>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8
MIME-Version: 1.0
To: Greg Smith <greg@2ndquadrant.com>
CC: Tom Lane <tgl@sss.pgh.pa.us>,
	Kevin Grittner <Kevin.Grittner@wicourts.gov>,
	Bruce Momjian <bruce@momjian.us>, jd@commandprompt.com,
	Scott Marlowe <scott.marlowe@gmail.com>,
	Steve Crawford <scrawford@pinpointresearch.com>,
	pgsql-performance@postgresql.org, Ben Chobot <bench@silentmedia.com>
Subject: Re: BBU Cache vs. spindles
References: <4CC04EA50200002500036C5E@gw.wicourts.gov>
	<201010211935.o9LJZTM21744@momjian.us>
	<4CC0513E0200002500036C68@gw.wicourts.gov>
	<4CC1094C.1090306@2ndquadrant.com> <13038.1287720327@sss.pgh.pa.us>
	<4CC1AFB3.3000903@2ndquadrant.com>
In-Reply-To: <4CC1AFB3.3000903@2ndquadrant.com>
Content-Type: multipart/alternative;
	boundary="------------050108020107080404020206"
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=-1.899 tagged_above=-10 required=5
	tests=BAYES_00=-1.9, HTML_MESSAGE=0.001
X-Spam-Level: 
X-Archive-Number: 201010/381
X-Sequence-Number: 40799

This is a multi-part message in MIME format.
--------------050108020107080404020206
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 2010-10-22 17:37, Greg Smith wrote:
>  I think that most people who have thought they were safe to turn off
>  full_page_writes in the past did so because they believed they were
>  in category (1) here.  I've never advised anyone to do that, because
>  it's so difficult to validate the truth of.  Just given that, I'd be
>  tempted to join in on suggesting this parameter just go away in the
>  name of safety, except that I think category (2) here is growing now.
>  ZFS is the most obvious example where the atomic write implementation
>  seems to always make disabling full_page_writes safe.

Can you point to some ZFS docs that tell that this is the case..  I'd be 
surprised
if it doesnt copy away the old block and replaces it with the new one 
in-place. The
other behaviour would quite quickly lead to a hugely fragmented 
filesystem that
performs next to useless and ZFS doesnt seem to be in that category..

   ...  All given my total lack of insight into ZFS.

-- 
Jesper




--------------050108020107080404020206
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html; charset=ISO-8859-1"
 http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
On 2010-10-22 17:37, Greg Smith wrote:<span style="white-space: pre;"><br>
&gt; I think that most people who have thought they were safe to turn
off<br>
&gt; full_page_writes in the past did so because they believed they were<br>
&gt; in category (1) here.&nbsp; I've never advised anyone to do that,
because<br>
&gt; it's so difficult to validate the truth of.&nbsp; Just given that, I'd
be<br>
&gt; tempted to join in on suggesting this parameter just go away in the<br>
&gt; name of safety, except that I think category (2) here is growing
now.<br>
&gt; ZFS is the most obvious example where the atomic write
implementation<br>
&gt; seems to always make disabling full_page_writes safe.<br>
</span><br>
Can you point to some ZFS docs that tell that this is the case..&nbsp; I'd
be surprised <br>
if it doesnt copy away the old block and replaces it with the new one
in-place. The<br>
other behaviour would quite quickly lead to a hugely fragmented
filesystem that <br>
performs next to useless and ZFS doesnt seem to be in that category..<br>
<br>
&nbsp; ...&nbsp; All given my total lack of insight into ZFS. <br>
<br>
-- <br>
Jesper<br>
<br>
<br>
<br>
</body>
</html>

--------------050108020107080404020206--