Re: SCSI vs SATA - Mailing list pgsql-performance

From Geoff Tolley
Subject Re: SCSI vs SATA
Date
Msg-id 4613E224.7050301@polimetrix.com
Whole thread Raw
In response to Re: SCSI vs SATA  ("jason@ohloh.net" <jason@ohloh.net>)
List pgsql-performance
jason@ohloh.net wrote:

> Good point. On another note, I am wondering why nobody's brought up
> the command-queuing perf benefits (yet). Is this because sata vs scsi
> are at par here? I'm finding conflicting information on this -- some
> calling sata's ncq mostly crap, others stating the real-world results
> are negligible. I'm inclined to believe SCSI's pretty far ahead here
> but am having trouble finding recent articles on this.

My personal thoughts are that the SATA NCQ opinion you've found is simply
because the workloads SATAs tend to be given (single-user) don't really
benefit that much from it.

> The servers are hooked up to a reliable UPS. The battery-backed cache
> won't hurt but might be overkill (?).

The difference is that a BBU isn't going to be affected by OS/hardware
hangs. There are even some SCSI RAID cards I've seen which can save your
data in case the card itself fails (the BBU in these cases is part of the
same module as the write cache memory, so you can remove them together and
put them into a new card, after which the data can be written).

I haven't checked into this recently, but IDE drives are notorious for
lying about having their internal write cache disabled. Which means that in
theory a BBU controller can have a write acknowledged as having happened,
consequently purge the data from the write cache, then when the power fails
the data still isn't on any kind of permanent storage. It depends how
paranoid you are as to whether you care about this edge case (and it'd make
rather less difference if the pg_xlog is on a non-lying drive).

HTH,
Geoff

pgsql-performance by date:

Previous
From: mark@mark.mielke.cc
Date:
Subject: Re: SCSI vs SATA
Next
From: Peter Schuller
Date:
Subject: Re: Scaling SELECT:s with the number of disks on a stripe