Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 7 Jun 2002 20:20:55 -0700 (PDT)
From:      Tom Samplonius <tom@sdf.com>
To:        ticso@cicely.de
Cc:        Joao Pedras <jpedras@webvolution.net>, freebsd-scsi@FreeBSD.ORG
Subject:   Re: sync cache
Message-ID:  <Pine.BSF.4.05.10206072015320.8638-100000@misery.sdf.com>
In-Reply-To: <20020607161919.GO66505@cicely5.cicely.de>

next in thread | previous in thread | raw e-mail | index | archive | help

On Fri, 7 Jun 2002, Bernd Walter wrote:

> >   I don't think that is a good idea for a device to lie about what it
> > supports.  The illegal command response is an appropriate response for an
> > unimplemented command, so OS knows that the command did not work.  FreeBSD
> > simply logs it to the console, and it is harmless.
> 
> If the device has nvram based cache it's completely legal to implement
> sync cache as a nop, as there realy is nothing to do.

  I believe the spec says the command must flush to disk, not battery
backed RAM.  Most of these systems only have retention for a few days.
That isn't permenent storage.  Not only that, you wouldn't know the
battery backed RAM had data on it, as the device lied to you and told you
it was written to disk!  Bad, bad, bad.

> In short: it does not lie when doing it.
> And the OS/User knows it's save to power off.
> In the current situation noone really knows if there is unsave data.
> It *does* harm if I don't know when I can savely power down.

  Same difference.  Either you lie, and the data may really not be on the
disk, or you report an error and know for sure that data may not be on the
disk.  The latter is better.

> >   BTW, most SCSI-SCSI RAID boxes don't implement the cache flush command.
> 
> Many RAID boxes have questionable command support.
> But that doesn't mean it's a good choice after all.
> They havn't thought about that simple command, which realy gives a bad
> taste.
> How could I beleave they have thought about the real critical commands?

  Seems the correct behaviour:  not implemented -> return error.  That is
the safest choice.  I don't want my hardware to lie to me about what it is
doing, when my data is at stake.

> -- 
> B.Walter              COSMO-Project         http://www.cosmo-project.de
> ticso@cicely.de         Usergroup           info@cosmo-project.de
> 
> 
> 

Tom


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?Pine.BSF.4.05.10206072015320.8638-100000>