Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 22 Oct 1998 22:10:03 -0700
From:      Don Lewis <Don.Lewis@tsc.tdk.com>
To:        "Justin T. Gibbs" <gibbs@plutotech.com>, Don Lewis <Don.Lewis@tsc.tdk.com>
Cc:        freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG
Subject:   Re: filesystem safety and SCSI disk write caching
Message-ID:  <199810230510.WAA19810@salsa.gv.tsc.tdk.com>
In-Reply-To: "Justin T. Gibbs" <gibbs@plutotech.com> "Re: filesystem safety and SCSI disk write caching" (Oct 22,  9:33pm)

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810230510.WAA19810>