Subject: Re: RAID controller safety
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Kenny Simpson <theonetruekenny@yahoo.com>
Cc: linux kernel <linux-kernel@vger.kernel.org>
In-Reply-To: <20051229162935.67301.qmail@web34106.mail.mud.yahoo.com>
References: <20051229162935.67301.qmail@web34106.mail.mud.yahoo.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: Fri, 30 Dec 2005 15:17:46 +0000
Message-Id: <1135955866.28365.10.camel@localhost.localdomain>
Mime-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1367
Lines: 29

On Iau, 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 i2o core drivers use the following rules

i2o_scsi issues SCSI commands and assumes they are pass through and that
the firmware does not fake completions early (or if it does that it
battery backs them). For the known hardware the i2o SCSI class interface
is a pass through interface with the card cpu just doing protocol gunk
and supervision

i2o_block by default assumes the card is caching. It adopts write
through mode if the controller has no battery, write back if it shows
battery. This can be configured differently via ioctls including the
ability to tune write through of large I/O's (to avoid cache thrashing),
and to do write back with no battery backup for performance in cases
where losing the data on a crash doesn't matter (eg swap)

Alan

-
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/