From owner-freebsd-scsi Thu Oct 22 22:16:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA22105 for freebsd-scsi-outgoing; Thu, 22 Oct 1998 22:16:56 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA22095; Thu, 22 Oct 1998 22:16:54 -0700 (PDT) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id XAA29829; Thu, 22 Oct 1998 23:16:23 -0600 (MDT) Message-Id: <199810230516.XAA29829@pluto.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Don Lewis cc: "Justin T. Gibbs" , freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: filesystem safety and SCSI disk write caching In-reply-to: Your message of "Thu, 22 Oct 1998 22:10:03 PDT." <199810230510.WAA19810@salsa.gv.tsc.tdk.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 22 Oct 1998 23:09:33 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >} There has been quite a bit of debate on how UAs should be handled. The >} original CAM driver was *very* conservative and returned all pending >} I/O with EIO, marked the pack invalid, and refused to take any I/O unless >} the device cycled through final close. This ensures that if the device >} or pack is replaced that you don't spam different media or even if the >} media is the same, make the problem worse by attempting to continue after >} some transactions were irrevocably lost. This was considered too >} disruptive and since a permanent solution could not be developed for >} 3.0R, the UA code was disabled. The correct solution likely requires >} better communication to the FS or user layer so that pack validation >} of some sort can occur. > >If write caching is disabled and if it is possible to verify that the >media is the same, it should be safe to retry all the lost I/O >transactions. You can't retry the transactions without first determining that the media is the same as before. We can't do that right now without manual intervention which shouldn't be the case. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message