🚀 go-pugleaf

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?

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.

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

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.

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.

-- 
     .^.^.      Dan Razzell <razzell@cs.ubc.ca>
    . o o .     Laboratory for Computational Intelligence
    . >v< .     University of British Columbia
_____mm.mm_____ http://www.cs.ubc.ca/nest/lci