Date: Sat, 14 Sep 2002 14:14:52 -0700 (PDT)
From: Andre Hedrick <andre@linux-ide.org>
To: Alex Davis <alex14641@yahoo.com>
cc: Alan Cox <alan@lxorguk.ukuu.org.uk>, miquels@cistron.nl,
       linux-kernel@vger.kernel.org
Subject: Re: Possible bug and question about ide_notify_reboot in 2.4.19
In-Reply-To: <20020914195223.48337.qmail@web40510.mail.yahoo.com>
Message-ID: <Pine.LNX.4.10.10209141359590.6925-100000@master.linux-ide.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2124
Lines: 50

On Sat, 14 Sep 2002, Alex Davis wrote:

> > Hint 1. Other people make disks too.
> I'm glad you and I realize that. It seems that others might not. So
> far, in this thread, only one person using one brand of disk (IBM)
> has found something in writing about the cache issue. Let's see, 
> that leaves Maxtor/Quantum, Seagate, Fujitsu, .....

I can list a bunch, but I know about them under heavy NDA's with anvils
looming over head.

Like what happens if a drive issues a self flush cache and receives an
error so the next issue from user/kernel space will cause the device to
internally deadlock.  Yeah this is a firmware bug, imho.  Yet when it was
to be addressed by the commitee, "NONE" of the drive vendors reported back
their behavior, iirc.  Thus the proposal was dropped.

> > Hint 2. The guys who did the code include a member of the standards
> > committee.
> And your point is...?? Does this somehow preclude them being wrong??

You should come in the room sometime and watch.
It is not so much being wrong, it is all in the language.

There are things in the standard, which make Bill Clinton look squeaky
clean.  You think Clinton's "is" was bad.

Try this one, "READ_VERIFY"

You issue a write to platter, then a read_verify to have the device do an
internal comparison.  Usually a bastardized benchmark pile of dung.
Some drive vendors in the past would pull the data out of dirty disk
buffer cache, and not off the platters.  Translation it never made it to
platter, and you never know if it did.  When caught by their competitors,
the language change to "shall have been read off the platter some time in
the past".  Yet you just issued a write to platter, so that means that
data can not have been read in the past but must be in the future.

Future/Past the pull it out of cache.

Want more to make your guts turn?

Andre Hedrick
LAD Storage Consulting Group

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/