libata FUA revisited
I've been looking at some list archives from about a year ago when there was a big hoohah about FUA in libata. To summarize what I've gotten from that discussion:
Nicolas Mailhot ran into a problem with the first kernels that supported libata FUA, using a Silicon Image 3114 controller and a Maxtor 6L300S0
drive with BANC1G10 firmware. Essentially it would quickly corrupt
the filesystem on bootup. After that:
-A blacklist entry was added into libata disabling FUA on Maxtor drives with BANC1G10 firmware
-Eric Mudama from Maxtor complained that there was nothing wrong with FUA on those drives and the blacklist should be taken out (though it never was)
-It was also confirmed by Eric and others that Silicon Image 311x controllers go nuts if they're issued WRITE DMA FUA commands, at least without some driver improvements which I assume haven't happened.
-Eventually FUA was disabled by default globally in libata.
Given the above, what I'm proposing to do is:
-Remove the blacklisting of Maxtor BANC1G10 firmware for FUA. If we need to FUA-blacklist any drives this should likely be added to the existing "horkage" mechanism we now have. However, at this point I don't think that's needed, considering that I've seen no conclusive evidence that any drive has ever been established to have broken FUA.
-Add a new port flag ATA_FLAG_NO_FUA to indicate that a controller can't handle FUA commands, and add that flag to sata_sil. Force FUA off on any drive connected to a controller with this bit set.
There was some talk that sata_mv might have this problem, but I believe the conclusion was that it didn't. The only controllers that would are ones that actually try to interpret the ATA command codes and don't know about WRITE DMA FUA.
-Change the fua module option to control FUA enable/disable to have a third value, "enable for NCQ-supporting drives only", which would become the new default. That case seems less likely to cause problems since FUA on NCQ is just another bit in the command whereas FUA on non-NCQ is an entirely different, potentially unsupported command.
Any comments?
As an aside, I came across a comment that the Silicon Image Windows drivers for NCQ-supporting controllers have some blacklist entries for drives with broken NCQ in their .inf files. We only seem to have one in the libata NCQ blacklist, we may want to add some more of these. The ones in the current SiI3124 and 3132 drivers' .inf files for "DisableSataQueueing" appear to be:
Model Firmware
Maxtor 7B250S0 BANC1B70
HTS541060G9SA00 MB3OC60D
HTS541080G9SA00 MB4OC60D
HTS541010G9SA00 MBZOC60D
(the latter 3 being Hitachi Travelstar drives)
Signature · 3 lines
Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [email protected] Home Page: http://www.roberthancock.com/
Hello,
Robert Hancock wrote:
[--correct summary snipped--]
Quoted 4 lines
Given the above, what I'm proposing to do is:
-Remove the blacklisting of Maxtor BANC1G10 firmware for FUA. If we need
to FUA-blacklist any drives this should likely be added to the existing "horkage" mechanism we now have. However, at this point I don't think that's needed, considering that I've seen no conclusive evidence that any drive has ever been established to have broken FUA.
Agreed.
Quoted 4 lines
-Add a new port flag
ATA_FLAG_NO_FUAto indicate that a controller can't
handle FUA commands, and add that flag tosata_sil. Force FUA off on any drive connected to a controller with this bit set.There was some talk that
sata_mvmight have this problem, but I believe the conclusion was that it didn't. The only controllers that would are ones that actually try to interpret the ATA command codes and don't know about WRITE DMA FUA.
I think it would be better to add ATA_FLAG_FUA instead of ATA_FLAG_NO_FUA.
Quoted 2 lines
-Change the fua module option to control FUA enable/disable to have a
third value, "enable for NCQ-supporting drives only", which would become the new default. That case seems less likely to cause problems since FUA on NCQ is just another bit in the command whereas FUA on non-NCQ is an entirely different, potentially unsupported command.
Not enabling FUA doesn't result in huge performance hit. I'm not sure whether we should go such far. Just supporting FUA on known good controllers sounds good enough to me.
Quoted 11 lines
Any comments?
As an aside, I came across a comment that the Silicon Image Windows drivers for NCQ-supporting controllers have some blacklist entries for drives with broken NCQ in their .inf files. We only seem to have one in the libata NCQ blacklist, we may want to add some more of these. The ones in the current SiI3124 and 3132 drivers' .inf files for "DisableSataQueueing" appear to be:
Model Firmware
Maxtor 7B250S0 BANC1B70HTS541060G9SA00 MB3OC60D HTS541080G9SA00 MB4OC60D HTS541010G9SA00 MBZOC60D(the latter 3 being Hitachi Travelstar drives)
Yeah, I don't think we need to be too careful about blacklisting NCQ considering the sorry state of many early NCQ firmwares. Please submit a patch. It would be nice if you add a comment why the drives are added for documentation.
Thanks.
Signature · 1 line
tejun
Quoted 9 lines · Tejun Heo
Hello,
Robert Hancock wrote:
[--correct summary snipped--]Quoted 4 lines
Given the above, what I'm proposing to do is:
-Remove the blacklisting of Maxtor BANC1G10 firmware for FUA. If we
need to FUA-blacklist any drives this should likely be added to the existing "horkage" mechanism we now have. However, at this point I don't think that's needed, considering that I've seen no conclusive evidence that any drive has ever been established to have broken FUA.
Quoted 8 lines
Agreed.
Quoted 4 lines
-Add a new port flag
ATA_FLAG_NO_FUAto indicate that a controller
can't handle FUA commands, and add that flag tosata_sil. Force FUA off on any drive connected to a controller with this bit set.There was some talk that
sata_mvmight have this problem, but I believe the conclusion was that it didn't. The only controllers that would are ones that actually try to interpret the ATA command codes and don't know about WRITE DMA FUA.I think it would be better to add
ATA_FLAG_FUAinstead ofATA_FLAG_NO_FUA.
This is an interesting (if small) problem. I would propose a third option: add ATA_FLAG_NO_FUA to applicable /SATA/ drivers, but leave those without ATA_FLAG_SATA alone.
Jeff