From: | Greg Smith <gsmith(at)gregsmith(dot)com> |
---|---|
To: | James Mansion <james(at)mansionfamily(dot)plus(dot)com> |
Cc: | Scott Carey <scott(at)richrelevance(dot)com>, Stef Telford <stef(at)ummon(dot)com>, Mark Kirkwood <markir(at)paradise(dot)net(dot)nz>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Raid 10 chunksize |
Date: | 2009-04-03 09:53:25 |
Message-ID: | alpine.GSO.2.01.0904030535060.4011@westnet.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Thu, 2 Apr 2009, James Mansion wrote:
> Might have to give the whole disk to ZFS with Solaris to give it
> confidence to enable write cache
Confidence, sure, but not necessarily performance at the same time. The
ZFS Kool-Aid gets bitter sometimes too, and I worry that its reputation
causes people to just trust it when they should be wary. If there's
anything this thread does, I hope it helps demonstrate how easy it is to
discover reality doesn't match expectations at all in this very messy
area. Trust No One! Keep Your Laser Handy!
There's a summary of the expected happy ZFS actions at
http://www.opensolaris.org/jive/thread.jspa?messageID=19264& and a good
cautionary tale of unhappy ZFS behavior in this area at
http://blogs.digitar.com/jjww/2006/12/shenanigans-with-zfs-flushing-and-intelligent-arrays/
and its follow-up
http://blogs.digitar.com/jjww/2007/10/back-in-the-sandbox-zfs-flushing-shenanigans-revisted/
Systems with a hardware write cache are pretty common on this list, which
makes the situation described there not that unlikely to run into. The
official word here is at
http://www.solarisinternals.com/wiki/index.php/ZFS_Evil_Tuning_Guide#FLUSH
--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2009-04-03 10:30:12 | Re: Raid 10 chunksize |
Previous Message | Greg Smith | 2009-04-03 09:29:10 | Re: Raid 10 chunksize |