More Adaptec 29320 + Seagate ST336607LW woes

Don Lewis truckman at FreeBSD.org
Wed Dec 10 12:08:19 PST 2003


On 10 Dec, ict technician wrote:
> On Saturday 06 December 2003 7:29 pm, Don Lewis wrote:
>> On  6 Dec, ian j hart wrote:
>> > On Friday 05 December 2003 8:33 pm, Don Lewis wrote:
>> >> I've been meaning to suggest that if you haven't done so already, use
>> >> "camcontrol modepage" to set the WCE bit to 0 which will disable write
>> >> caching on the drive.  In the testing that I've done, I haven't seen any
>> >> significant performance penalty in doing this if tagged command queuing
>> >> and softupdates are in use.  It is also safer for soft updates because
>> >> the drive no longer lies about when write data reaches stable storage.
> 
> I'll add it to my "things to try" list. Don't want to compromise the data I'm
> collecting tho'. ie it's a new variable to the equasion.
> 
> A deep tagged commands queue would be a bit like a cache, wouldn't it? I
> suspect you would see a significant performance decrease if you also reduced
> the queue depth.

It probably depends a lot on the characteristics of the I/O load.  The
drive may be able to more optimistically schedule the physical I/O if it
has a bigger queue to work with.  For example, if reads or writes to
nearby sectors are separated by many commands, a larger queue depth may
allow the drive to see both commands and cluster the physical I/O,
whereas it would not be able to do this if both commands were not in the
queue at the same time.

> <semi-rhetorical>What happens to the queue when I press the power switch?

Any queued writes are lost, along with the soft updates work queue, and
a sector being written at the time might be corrupted.  Other than the
bad sector, the file system will be in a consistent state and fsck
should be able to repair it.  The data lost in the disk queue will also
still be in the soft updates work queue, so it is essentially the last N
seconds of file writes.

The file system may well not be left in a consistent state after a power
loss if WCE is on, which means that fsck may not be able to do an
automatic repair and may require manual intervention.

The data for any file is guaranteed to be on the platter after an
fsync() if WCE is off, but not if it is on. The latter means that if you
use fsync() a lot, you'll see a performance hit.


More information about the freebsd-scsi mailing list