content-class: urn:content-classes:message
Subject: RE: RAID controller safety
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 8BIT
Date: Fri, 6 Jan 2006 09:33:12 -0500
Message-ID: <547AF3BD0F3F0B4CBDC379BAC7E4189F02026FB0@otce2k03.adaptec.com>
Thread-Topic: RAID controller safety
Thread-Index: AcYNU/2ljKq6GzgWRCOSJAK035IoVwFckikQ
From: "Salyzyn, Mark" <mark_salyzyn@adaptec.com>
To: "Alan Cox" <alan@lxorguk.ukuu.org.uk>,
       "Kenny Simpson" <theonetruekenny@yahoo.com>
Cc: "linux kernel" <linux-kernel@vger.kernel.org>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1074
Lines: 24

Alan Cox sez:
> 2005-12-29 at 08:29 -0800, Kenny Simpson wrote:
> > Specificly, I am looking at the Adaptec RAID controllers 
> > and their i2o drivers.  I am told the
> > kernel's i2o driver lacks a strong guarantee on fsync, and 
> > so far am unable to determine if the
> > dpt_i2o driver also falls short in this reguard.
> Only dpt can tell you what their firmware actually does.

The dpt_i2o driver (which is a scsi driver) accepts the
SYNCHRONIZE_CACHE scsi command and passes it off to the firmware. The
firmware respects this and flushes all the outstanding (cached)
commands. This is true in all (kernel.org or Adaptec latest) versions.

The only environment, in my memory, that this has been tested is in the
ASR driver in FreeBSD, where this behavior is necessary in support of
cluster checkpointing.

-- Mark Salyzyn
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/