DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
	b=HzuBfn7sxQnKM3xSP01mgdyPqswevpqnO3zEycelzVIiAdmNbrqo03SBQGUhfanjwAJI5qqEUlS6pe6rha481Kgxr6fca+VCkptXLglftotTt1G/1yeMVWIPpdXStbnOdVgfOTIfIkLPRkV7O6Qxw8vDNcLr9Z/WcGU5Fk88HaA=
Message-ID: <b6e8f2e80702270027s1c684f42vb3eca0a1d87ed5fb@mail.gmail.com>
Date: Tue, 27 Feb 2007 09:27:52 +0100
From: "Peter Kovacs" <maxottovonstirlitz@gmail.com>
To: "Shane Ambler" <pgsql@sheeky.biz>
Subject: Re: Two hard drives --- what to do with them?
Cc: "Jeff Davis" <pgsql@j-davis.com>, "Tom Lane" <tgl@sss.pgh.pa.us>,
	"Carlos Moreno" <moreno_pg@mochima.com>, pgsql-performance@postgresql.org
In-Reply-To: <45E3BC09.60100@Sheeky.Biz>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <45DF3B15.1070609@3times25.net> <45DF94BF.6050904@3times25.net>
	<45E0A500.1010707@commandprompt.com> <45E104DD.3080600@mochima.com>
	<2055.1172375931@sss.pgh.pa.us>
	<b6e8f2e80702251411q5a27eb53re9c2a299b8e3880a@mail.gmail.com>
	<1172526666.10824.315.camel@dogma.v10.wvs>
	<b6e8f2e80702261611j598b1771g3dbcfc9bb1f9cdf2@mail.gmail.com>
	<1172535914.10824.327.camel@dogma.v10.wvs> <45E3BC09.60100@Sheeky.Biz>

On 2/27/07, Shane Ambler <pgsql@sheeky.biz> wrote:
> Jeff Davis wrote:
>
> >> Sorry for for not being familar with storage techonologies... Does
> >> "battery" here mean battery in the common sense of the word - some
> >> kind of independent power supply? Shouldn't the disk itself be backed
> >> by a battery? As should the entire storage subsystem?
> >>
> >
> > Yes, a battery that can hold power to keep data alive in the write cache
> > in case of power failure, etc., for a long enough time to recover and
> > commit the data to disk.
>
> Just to expand a bit - the battery backup options are available on some
> raid cards - that is where you would be looking for it. I don't know of
> any hard drives that have it built in.
>
> Of cause another reason to have a UPS for the server - keep it running
> long enough after the clients have gone down so that it can ensure
> everything is on disk and shuts down properly.
>
> > So, a write cache is OK (even for pg_xlog) if it is durable (i.e. on
> > permanent storage or backed by enough power to make sure it gets there).
> > However, if PostgreSQL has no way to know whether a write is durable or
> > not, it can't guarantee the data is safe.
> >
> > The reason this becomes an issue is that many consumer-grade disks have
> > write cache enabled by default and no way to make sure the cached data
> > actually gets written. So, essentially, these disks "lie" and say they
> > wrote the data, when in reality, it's in volatile memory. It's
> > recommended that you disable write cache on such a device.
>
>  From all that I have heard this is another advantage of SCSI disks -
> they honor these settings as you would expect - many IDE/SATA disks
> often say "sure I'll disable the cache" but continue to use it or don't
> retain the setting after restart.

As far as I know, SCSI drives also have "write cache" which is turned
off by default, but can be turned on (e.g. with the sdparm utility on
Linux). The reason I am so much interested in how write cache is
typically used (on or off) is that I recently ran our benchmarks on a
machine with SCSI disks and those benchmarks with high commit ratio
suffered significantly compared to our previous results
"traditionally" obtained on machines with IDE drives.

I wonder if running a machine on a UPS + 1 hot standby internal PS is
equivalent, in terms of data integrity, to using battery backed write
cache. Instinctively, I'd think that UPS + 1 hot standby internal PS
is better, since this setup also provides for the disk to actually
write out the content of the cache -- as you pointed out.

Thanks
Peter

>
>
> --
>
> Shane Ambler
> pgSQL@Sheeky.Biz
>
> Get Sheeky @ http://Sheeky.Biz
>