Xref: utzoo comp.unix.aix:744 comp.periphs.scsi:192
Path: utzoo!attcan!uunet!clyde.concordia.ca!news-server.csri.toronto.edu!rutgers!apple!xanadu!michael
From: michael@xanadu.com (Michael McClary)
Newsgroups: comp.unix.aix,comp.periphs.scsi
Subject: Re: Risc System/6000
Message-ID: <1990Mar19.130118.15809@xanadu.com>
Date: 19 Mar 90 13:01:18 GMT
References: <1660@aber-cs.UUCP> <51507@sgi.sgi.com> <PCG.90Mar2184300@rupert.cs.aber.ac.uk> <1990Mar9.022931.4674@world.std.com> <132788@sun.Eng.Sun.COM> <1990Mar13.190317.17846@utzoo.uucp>
Organization: Xanadu Operating Company, Palo Alto, CA
Lines: 44

In article <1990Mar13.190317.17846@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>In article <132788@sun.Eng.Sun.COM> mjacob@sun.UUCP (Matt Jacob) writes:
>>... With the coming of SCSI-2
>>multiple command targets, it seems to me that one should just
>>concentrate on getting requests out to the target as quickly
>>as possible and let the microprocessor on the drive figure out
>>the best order do them in.
>
>This is reasonable, provided that (a) one can impose constraints on the
>ordering to meet filesystem-integrity requirements, and (b) the micro
>on the drive has enough queue space for (potentially) hundreds of
>requests.  I'm not holding my breath.

I hereby spend a little of the net's bandwith to point out, especially
to the authors of drive firmware, that (a) is VERY important.

VERY VERY VERY VERY VERY VERY VERY VERY VERY VERY VERY VERY important.

A drive that does no write-order optimization whatsoever is usable
for a high-reliability database.

A drive that buffers and re-orders writes is UNusable UNLESS its
write order can be constrained (or neither it nor the computer it
is connected to EVER suffer any failures or unexpected shutdowns).

The smallest simple-to-implement constraint I know is to be able to
tell the drive "Be sure everything you got before >NOW< is written
and power-fail safe before writing anything you get after >NOW<."
If you can't give me at least that, write the data in the order you
got it.

The constraint "Be sure everything you got before >NOW< is written
and power-fail safe before allowing another operation to start."
is sufficient, but causes an unnecessary performance hit for some
applications.

Thank you for your attention.

=========================================================================
I normally have the option of turning opinions expressed in my postings
into 1/5 of 1% of the opinion of Xanadu Operating Company.

On this issue, my opinion >IS< the opinion of Xanadu Operating Company.
=========================================================================