From owner-freebsd-scsi  Thu Oct 22 22:10:40 1998
Return-Path: <owner-freebsd-scsi@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id WAA21437
          for freebsd-scsi-outgoing; Thu, 22 Oct 1998 22:10:40 -0700 (PDT)
          (envelope-from owner-freebsd-scsi@FreeBSD.ORG)
Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA21428;
          Thu, 22 Oct 1998 22:10:37 -0700 (PDT)
          (envelope-from gdonl@tsc.tdk.com)
Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191])
	by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id WAA09885;
	Thu, 22 Oct 1998 22:10:06 -0700 (PDT)
	(envelope-from gdonl@tsc.tdk.com)
Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194])
	by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id WAA17645;
	Thu, 22 Oct 1998 22:10:05 -0700 (PDT)
Received: (from gdonl@localhost)
	by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id WAA19810;
	Thu, 22 Oct 1998 22:10:04 -0700 (PDT)
From: Don Lewis <Don.Lewis@tsc.tdk.com>
Message-Id: <199810230510.WAA19810@salsa.gv.tsc.tdk.com>
Date: Thu, 22 Oct 1998 22:10:03 -0700
In-Reply-To: "Justin T. Gibbs" <gibbs@plutotech.com>
       "Re: filesystem safety and SCSI disk write caching" (Oct 22,  9:33pm)
X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95)
To: "Justin T. Gibbs" <gibbs@plutotech.com>, Don Lewis <Don.Lewis@tsc.tdk.com>
Subject: Re: filesystem safety and SCSI disk write caching
Cc: freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

On Oct 22,  9:33pm, "Justin T. Gibbs" wrote:
} Subject: Re: filesystem safety and SCSI disk write caching

} The driver will notice as the drive will notice an issue a Unit Attention
} response the next time you touch it.  Or is your point that you won't
} necessarily access the device again and so never see that the device
} saw a loss in power?

I forgot about Unit Attention.  At least it will be obvious that the
filesystem is potentially corrupted and there is a hardware problem
that needs fixing.

} 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.

If write caching is off and softupdates is in use, your original solution
still works ok even if someone yanks the media out of the drive.  The
filesystem will still be intact, though it might not be totally up to date.

If write caching is on, you're basically SOL if you see a Unit Attention.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message