[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



On 08/23/2010 10:01 AM, Jens Axboe wrote:
On 2010-08-23 15:58, Ric Wheeler wrote:
On 08/23/2010 08:48 AM, Christoph Hellwig wrote:
On Mon, Aug 23, 2010 at 02:30:33PM +0200, Tejun Heo wrote:
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?



Hi Jens,

There are actually two distinct problems:

(1) arrays with a non-volatile write cache (battery backed, navram, whatever) that do not NOOP a SYNC_CACHE command. I know of one brand that seems to do this, but it is not a common brand. If we do not issue flushes for write through caches, I think that we will avoid this in any case.

(2) hardware raid cards with internal buffer memory and on-card battery backup (they sit in your server, disks sit in jbod like expansion shelves). These are fine if the drives in those shelves have write cache disabled.

ric


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]