Date: Mon, 19 Oct 1998 19:11:26 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: gibbs@plutotech.com (Justin T. Gibbs) Cc: tlambert@primenet.com, julian@whistle.com, guido@gvr.org, dkelly@hiwaay.net, freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: filesystem safety and SCSI disk write caching Message-ID: <199810191911.MAA02817@usr02.primenet.com> In-Reply-To: <199810191810.MAA06527@pluto.plutotech.com> from "Justin T. Gibbs" at Oct 19, 98 12:04:00 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >> Perhaps you should add the SCSI II and SCSI II specs to your list of things > >> to read. > > > >Feel free to engage in Ad Hominim attacks... > > If it was an attack, it was self-inflicted. You should know better > than to make statements on topics you do not fully comprehend. It > is blatantly obvious to anyone who has read the spec that you either > have not read the spec or did not comprehend it. It is only fair > to ensure that the less informed people on this list know that you > are anything but an expert on SCSI and they should take you comments > as uninformed supposition at best. > > If you don't want to be 'attacked' stop throwing FUD around on our lists. I am not presuming to be an expert on SCSI. I *am* presuming to tell you that Don's experiences, and my own, contradict your interpretation of the spec. This is not to say your interpretation is wrong, but it could easily be the case that the drive or controller is not 100% compliant. Jumping down my throat about intepretation of the spec. because the empirically observed behaviour contradicts your knowledge of the spec. (I do not question that your knowledge of the spec. far exceeds mine) resolves nothing. > >, *after* you explain why > >Don Lewis is seeing the empirical behaviour he is seeing, in > >contradiction to your claims of what's possible and not. > > I've already given my opinion on this. I believe the Hawk is seeing > a power glitch or temporary power loss when the reset switch is hit and > so the contents of the cache are lost. I have never said that the > behavior that Don Lewis is seeing is 'not possible', only that, for > the drive in question, the reset causing cache corruption is not likely. > Pluto has validated the Hawk for use in our RAID 3 systems, and part of > this validation includes spurious bus resets. This behavior was never > encountered in our tests. I personally still think it has something to do with what happens when the controller POSTs. I would like to see the following from Don before we simply accept a "magic power glitch": 1) Reset via software instead of via the reset switch 2) Use of a seperate power supply for the drive during reset This will decisively localize it to one side or the other of the bus. If the problem still occurs after 1 but doesn't after 2, then it's time to put a scope on the supply line to the drive. As a datapoint, I have an NCR controller, and the problem occurs on my external SyJet 1.5G drive, which, by definition, has its own power supply, which I would be hard pressed to believe was affected by my hitting the front panel reset but on my seperately supplied computer. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810191911.MAA02817>