On Sat, 5 Apr 2003, Mudama, Eric wrote:
> In either case, according to the spec, when a FLUSH CACHE (normal or EXT,
> doesn't matter) completes with "good" status (0x50) all the write cache has
> been successfully flushed to the disk.
>
> A 48-bit sized drive should still commit dirty data when issued the 28-bit
> FLUSH CACHE command, it will simply have problems reporting potential error
> locations if it gets a fatal error on the write.
>
> > You will not be allowed to push off the 48-bit feature set rules.
> > Regardless if the new smart data is set the the GPL and not Smart
> > Logs.
>
> I don't understand what you mean. I am looking at the ATA7 r1a spec now,
> and don't see the 48-bit specific feature set rules that you're referring to
> being "pushed off".
This is the result of a flush cache error returning a failure and the
device logging the error. If it was a 48-bit command it should commit to
the GPL (smart extentions), otherwise a 28-bit would commit to 28-bit
smart logs. Since the Linux does not track the returns on completion, the
report of any flush cache error is worthless. Since the error reports the
LBA where it happened but that request is long gone, the data is toast.
It will take 2.7 or later to address the data integrity and recovery on a
device that fails completion on a flush. This is a bad host, but the host
is getting smarter. The difference is this host's author knows the
issues, and just needs to communicate them out.
> >If you are suggesting a pole for completion on the FLUSH, say so.
> >Otherwise, standard non-data INTQ completion is default.
>
> Clearing of the busy bit with a status of 0x50 is what to look for. Polled
> or INTQ doesn't matter.
>
> If the drive reports 0x50 without a completely clean write cache, it is
> broken.
This is a DEVICE side problem, the HOST can only respond to the content
returned in the taskfiles. The DEVICE can LIE all day long and the HOST
can only follow the lead cue from the DEVICE.
Cheers,
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/
This archive was generated by hypermail 2b29 : Mon Apr 07 2003 - 22:00:26 EST