Thread (109 messages) 109 messages, 19 authors, 2011-01-14

Re: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush

From: Jens Axboe <hidden>
Date: 2010-08-23 14:01:15
Also in: dm-devel, linux-fsdevel, linux-ide, linux-scsi, lkml

On 2010-08-23 15:58, Ric Wheeler wrote:
On 08/23/2010 08:48 AM, Christoph Hellwig wrote:
quoted
On Mon, Aug 23, 2010 at 02:30:33PM +0200, Tejun Heo wrote:
quoted
It might be useful to give several example configurations with
different cache configurations.  I don't have much experience with
battery backed arrays but aren't they suppose to report write through
cache automatically?
They usually do.  I have one that doesn't, but SYNCHRONIZE CACHE on
it is so fast that it effectively must be a no-op.
Arrays are not a problem in general - they normally have internally, redundant 
batteries to hold up the cache.

The issue is when you have an internal hardware RAID card with a large cache. 
Those cards sit in your server and the batteries on the card protect its 
internal cache, but do not have the capacity to hold up the drives behind it.

Normally, those drives should have their write cache disabled, but sometimes 
(especially with S-ATA disks) this is not done.
The problem purely exists on arrays that report write back cache enabled
AND don't implement SYNC_CACHE as a noop. Do any of them exist, or are
they purely urban legend?

-- 
Jens Axboe
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help