02.03.2011 03:54, Robert Hancock wrote: > On 03/01/2011 02:33 PM, Markus Trippelsdorf wrote: >> FUA support is currently switched off by default in >> drivers/ata/libata-core.c. >> Given that many modern drives do support FUA now, wouldn't it make sense >> to switch it on without setting a (undocumented) kernel/module >> parameter? After reading your email Markus, I rebooted two my home boxes after adding libata.fua=1 to the kernel line. And to my surprize, only one, the oldest, drive from 3 I have supports it. I've two WDs, one is the famous WD20EARS (first series with "advanced format", ie, 4kb sectors, and 2Tb size) which is less than half a year old, and another WD7500AACS, 750Gb, their prev-gen variant, both "green" series. And another from Hitachi, one of their "enterprize" series, 500Gb HUA7210, bought about 3 years ago. >From the 3, only Hitachi reports "supports DPO and FUA" after rebooting with fua=1. > I believe I proposed this some time ago. Essentially all modern drives > should support FUA now, since it's part of the definition of the NCQ > (FPDMA) read/write commands. However, as I recall one of the objections > to enabling it was that since it's just a bit in a command, there's a > possibility that some drives may ignore it by accident or design, which > is less likely with an explicit cache flush command. I'm not very > inclined to agree myself (if you go down that road of pre-emptively > predicting drive implementer stupidity, where do you stop?) but that's > what was raised. This is interesting as per above - the WDs I have definitely supports NCQ, and does that quite well (their scalability is a bit better than the one from Hitachi), but does not support FUA, or at least linux treats them as such. > Another complication is that NCQ can be disabled at runtime either by > user request or by error-handling fallback, and not all drives that > support NCQ also support the FUA versions of the non-NCQ read/write > commands, so changes in NCQ enable status may also need to result in > changes in FUA support status on the block device. Well, the only way to find out is to actually try to enable it. So far, the hitachi drive (which is a main drive on this my workstation, -- system, development, compilation etc) works without issues, and kernel compile time reduced for about 2% (I didn't perform good tests so far, so that 2% may be just random noize - will take a closer look in a few days to this). > I believe the way the block layer uses it, basically it only saves the > overhead of one transaction to the drive. It might be significant on > some workloads (especially on high IOPS drives like SSDs) but it's > likely not a huge deal. One transaction per what? If it means extra, especially "large" transaction (lile flush with a wait) per each fsync-like call, that can be huge deal actually, especially on database-like workloads (lots of small syncronous random writes). Thanks! /mjt -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
