Re: SSD + RAID - Mailing list pgsql-performance

From Ron Mayer
Subject Re: SSD + RAID
Date
Msg-id 4B82C642.8020409@cheapcomplexdevices.com
Whole thread Raw
In response to Re: SSD + RAID  (Bruce Momjian <bruce@momjian.us>)
Responses Re: SSD + RAID  (Greg Smith <greg@2ndquadrant.com>)
Re: SSD + RAID  (david@lang.hm)
List pgsql-performance
Bruce Momjian wrote:
> Greg Smith wrote:
>> .... If you have a regular SATA drive, it almost certainly
>> supports proper cache flushing....
>
> OK, but I have a few questions.  Is a write to the drive and a cache
> flush command the same?

I believe they're different as of ATAPI-6 from 2001.

> Which file systems implement both?

Seems ZFS and recent ext4 have thought these interactions out
thoroughly.   Find a slow ext4 that people complain about, and
that's the one doing it right :-).

Ext3 has some particularly odd annoyances where it flushes and waits
for certain writes (ones involving inode changes) but doesn't bother
to flush others (just data changes).   As far as I can tell, with
ext3 you need userspace utilities to make sure flushes occur when
you need them.    At one point I was tempted to try to put such
userspace hacks into postgres.

I know less about other file systems.  Apparently the NTFS guys
are aware of such stuff - but don't know what kinds of fsync equivalent
you'd need to make it happen.

Also worth noting - Linux's software raid stuff (MD and LVM)
need to handle this right as well - and last I checked (sometime
last year) the default setups didn't.

>  I thought a
> write to the drive was always assumed to flush it to the platters,
> assuming the drive's cache is set to write-through.

Apparently somewhere around here:
http://www.t10.org/t13/project/d1410r3a-ATA-ATAPI-6.pdf
they were separated in the IDE world.

pgsql-performance by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: shared_buffers
Next
From: Joel Jacobson
Date:
Subject: plpgsql plan cache