🚀 go-pugleaf

In article <41ddrs$8v4@nnrp.cs.ubc.ca>, Dan Razzell <razzell@cs.ubc.ca> wrote:
>In article <DDEuFG.2LJ@ftel.co.uk>,
>I.G.Batten@ftel.co.uk (Ian G Batten) writes:
>
>> ...
>> What I can't understand from what tls is saying
>> is why an NVRAM-equipped SCSI controller isn't sufficient to guard
>> against the scenario he describes (power failure with writes uncommitted
>> to disk)?  We have a Write Accelerator in our Auspex, and I think I
>> understand how it works.  Why is an NVRAM+disk combination any less
>> secure than a disk alone?
>
>Basically because system or component failure may leave you with a
>coherency problem to untangle, just at a time when you are probably
>worried about a lot of other things.  The host thinks that the I/O has
>completed, but how far did it get really before the hardware failed?  As
>you go about the task of identifying the surviving components and
>replacing the failed ones, which do you believe has the real state on
>them, and which are working but corrupted?  How do you preserve this
>state while configuring in new components, and how can you verify that
>it has been propagated correctly when you are ready to put the system
>back into service?

WHAT HE SAID WUZ .  .  .  It isn't, other than the reliability factor of
adding more components to the mix.  Like when disk heads on two
different drives start peeling up emulsion at the same time the power
goes out on an unprotected drive, shit man you might have some trouble
with data recovery, know what I mean?

>We use host NVRAM plus a Fast/Wide bus for one of our production file
>servers, and it performs quite satisfactorily.  We've had various disk
>failures and emergency shutdowns without any extraordinary recovery
>problems so far.  On that basis, the benefits have outweighed the
>costs.  We know that in the worst case we could restore everything from
>overnight backup, and for a research lab that's probably close enough.

And of course the NVRAM INSIDE the computer system is _way_ more
reliable than the shitty NVRAM inside the StorComp box?  Or that NVRAM
is an acceptable hedge against power failure which should never happen
anyway.  Which?

>> Why does the code at the host end of the SCSI
>> chain need to know that the far end has a cache with NVRAM?  Surely,
>> provided any acknowledged write down the SCSI chain can be followed
>> (possibly after a power fail) with a correct read from the same location
>> on disk, everyone is happy?

>I guess the ideal implementation along these lines is a disk with some
>amount of onboard NVRAM, so that you can treat the whole thing as a
>monolithic unit.  If it works, then as you say, everyone is happy.  If
>it fails, then it really doesn't matter if the failure is in the cache
>or the HDA, you can afford to replace the whole unit, so everyone is at
>least relatively happy, and nobody needs to be terribly sophisticated.

Most common SCSI drives are achieving the phenomenal performance numbers
they are getting by spinning faster, using ram to buffer track reads,
and implementing write-back cache.  So unless you are sure all THAT is
turned off too, . . .

>If the NVRAM were on a disk array, this strategy would cause you to
>throw out the whole array subsystem.  I don't think everyone would be
>quite so happy about that, especially if the subsystem is proprietary
>and its inner workings not completely revealed.

Huh? Guy said that the NVRAM was on a PCMCIA card or something, user
replaceable at any rate.  .  .  _ANY_ kind of disk array unless it is
done in software (1776, Veritas, ODT5) is gonna have some proprietary
guts.  Hell even the _SOFTWARE_ is proprietary, I mean, jeez.  The
StorComp guy says their arrays take off the shelf disks, just add them
on, so unless the failure is on the proprietary component this is a
non-argument.  It's like saying you have a bad 72pin SIMM on your
motherboard, so you throw out the computer or something.  C'mon now, we
are all computer people can we not think logically?

>If, as in our case, the NVRAM were on the host, the problem is even less
>localized, and you really have to think about what to do when something
>goes wrong.  On the bright side, the each of the components are fairly
>well understood, so you at least have something to work on.

It's all performance vs risk.  The higher the performance the greater
the risk, BUT, you can bring hardware failure risks so close to ZERO
with deep enough pockets that data loss from hardware failure can be
practically non-existant.

If you are extremely paranoid, you could MIRROR a pair of external raid
cabinets with a pair of uninterruptable power supplies, and stuff them
on independent SCSI busses/cards in a fault tolerant CPU setup from
TANDEM or something.  Hook the UPS's into an automatic diesel generator
and you really won't spend all that much money for a reliability factor
so close to 100% an some really super performance.

People always talk like the hardware in the external RAID cabinet is
more likely to die than in your CPU cabinet.  I tell you this, it's not
pretty when the CPU fan dies on your DX2/66 in a well stuffed cabinet.
--
Keith Smith <keith@ksmith.com>                  Free Usenet News/Newsfeeds
Digital Designs                                   (910) 423-4216/7389/7391
PO Box 85                                                   V.34/V.34/V.32
Hope Mills, NC 28348-0085  ... Somewhere in the Styx of North Carolina ...