Message-ID: <49D50F0E.6050807@mansionfamily.plus.com>
Date: Thu, 02 Apr 2009 20:16:30 +0100
From: James Mansion <james@mansionfamily.plus.com>
Organization: MsgWare
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Greg Smith <gsmith@gregsmith.com>
CC: Scott Carey <scott@richrelevance.com>, Stef Telford <stef@ummon.com>,
	Mark Kirkwood <markir@paradise.net.nz>, pgsql-performance@postgresql.org
Subject: Re: Raid 10 chunksize
References: <C5F933B9.40BB%scott@richrelevance.com>
	<alpine.GSO.2.01.0904020437080.17611@westnet.com>
In-Reply-To: <alpine.GSO.2.01.0904020437080.17611@westnet.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Greg Smith wrote:
> OK, that's clearly cached writes where the drive is lying about fsync. 
> The claim is that since my drive supports both the flush calls, I just 
> need to turn on barrier support, right?
>
That's a big pointy finger you are aiming at that drive - are you sure 
it was sent the flush instruction?  Clearly *something* isn't right.

> This is basically how this always works for me:  somebody claims 
> barriers and/or SATA disks work now, no really this time.  I test, 
> they give answers that aren't possible if fsync were working properly, 
> I conclude turning off the write cache is just as necessary as it 
> always was.  If you can suggest something wrong with how I'm testing 
> here, I'd love to hear about it.  I'd like to believe you but I can't 
> seem to produce any evidence that supports you claims here.
Try similar tests with Solaris and Vista?

(Might have to give the whole disk to ZFS with Solaris to give it 
confidence to enable write cache, which mioght not be easy with a laptop 
boot drive: XP and Vista should show the toggle on the drive)

James