Of course, 6-10 is the non-error case. Depending on how hard one has been
pounding the drive with writes, there is no reason that error recovery can't
creep up into the multiple-minute domain in some cases if you happen to have
excessively high temperature, vibrations, and be working on an old drive
with ratty servo bursts in a certain location or something.
> FLUSH CACHE/FLUSH CACHE EXT ...
>
> If you have a drive that is not larger than 28-bit in geometry
> regardless if it supports the 48-bit feature set, if it fails
> to comply with 28-bit flush cache it is a "BAD DEVICE", period.
Agreed. They're different opcodes, E7 and EA.
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".
>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.
-
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/