Skip site navigation (1) Skip section navigation (2)

Re: SSD + RAID

From: Greg Smith <greg(at)2ndquadrant(dot)com>
To: Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: SSD + RAID
Date: 2010-02-28 05:06:36
Message-ID: 4B89F9DC.6010304@2ndquadrant.com (view raw or flat)
Thread:
Lists: pgsql-performance
Ron Mayer wrote:
> Linux apparently sends FLUSH_CACHE commands to IDE drives in the
> exact sample places it sends SYNCHRONIZE CACHE commands to SCSI
> drives[2].
>   [2] http://hardware.slashdot.org/comments.pl?sid=149349&cid=12519114
>   

Well, that's old enough to not even be completely right anymore about 
SATA disks and kernels.  It's FLUSH_CACHE_EXT that's been added to ATA-6 
to do the right thing on modern drives and that gets used nowadays, and 
that doesn't necessarily do so on most of the SSDs out there; all of 
which Bruce's recent doc additions now talk about correctly.

There's this one specific area we know about that the most popular 
systems tend to get really wrong all the time; that's got the 
appropriate warning now with the right magic keywords that people can 
look into it more if motivated.  While it would be nice to get super 
thorough and document everything, I think there's already more docs in 
there than this project would prefer to have to maintain in this area.

Are we going to get into IDE, SATA, SCSI, SAS, FC, and iSCSI?  If the 
idea is to be complete that's where this would go.  I don't know that 
the documentation needs to address every possible way every possible 
filesystem can be flushed. 

-- 
Greg Smith  2ndQuadrant US  Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com   www.2ndQuadrant.us


In response to

Responses

pgsql-performance by date

Next:From: Tom LaneDate: 2010-02-28 16:42:39
Subject: Re: How to troubleshoot high mem usage by postgres?
Previous:From: Ron MayerDate: 2010-02-28 04:05:16
Subject: Re: SSD + RAID

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group