Re: [PATCH v7 0/7] Improve libata support for FUA

[Damien Le Moal <damien.lemoal@opensource.wdc.com>]

On 1/5/23 01:49, Tejun Heo wrote:
> Hello,
> 
> On Tue, Jan 03, 2023 at 02:19:17PM +0900, Damien Le Moal wrote:
>> Finally, patch 7 enables FUA support by default in libata for devices
>> supporting this features.
> 
> These optional features tend to be broken in various and subtle ways,

FUA is not optional for any drive that supports NCQ. The FUA bit is a
mandatory part of the FPDMA READ/WRITE commands. The optional part is
support for the non-ncq WRITE FUA EXT command.

> especially the ones which don't show clear and notable advantages and thus
> don't get used by everybody. I'm not necessarily against enabling it by
> default but we should have better justifications as we might unnecessarily
> cause a bunch of painful and subtle failures which can take a while to sort
> out.

Avoiding regressions is always my highest priority. I know that there
are a lot of cheap ATA devices out there that have questionable ACS spec
compliance.

> * Can the advantages of using FUA be demonstrated in a realistic way? IOW,
>   are there workloads which clearly benefit from FUA? My memory is hazy but
>   we only really use FUA from flush sequence to turn flush, write, flush
>   sequence into flush, FUA-write. As all the heavy lifting is done in the
>   first flush anyway, I couldn't find a case where that optimization made a
>   meaningful difference but I didn't look very hard.

The main users in kernel are file systems, when committing
transactions/metadata journaling. Given that this is generally not
generating a lot of traffic, I do not think we can measure any
difference for HDDs. The devices are too slow to start with, so saving
one command will not matter much, unless the application is fsync()
crazy (and even then, not sure we'll see any difference). Even for SATA
SSDs it likely will be hard to see a difference I think.

Then we have applications using the drive block device file directly.
For these, it is hard to tell how much it matters. Enabling it by
default with a drive correctly supporting it will very much likely not
hurt though.

Maciej,

May be you did some experiments before asking for enabling FUA by
default ? Any interesting performance data you can share ?

> * Do we know how widely FUA is used now? IOW, is windows using FUA by
>   default now? If so, do we know whether they have a blocklist?

You mean "blacklist" ? I do not have any information about Windows, but
I can try to find out, at least for my employer's devices. But that will
not be very useful as I know these drives behave correctly.

More than Windows or the kernel, I think that looking at SAS HBAs is
more important here. SATA HDDs are the most widely used type of devices
with these, by far. These may have a SAT translating FUA scsi writes to
FUA NCQ FPDMA writes, resulting in FUA being extensively used. Modulo a
blacklist that results in the same as the kernel with a
flush/write/flush sequence. Hard to know as HBA's FW are not open. A bus
analyzer could tell us that though, but again I can look at that only
with the drives I have, which I know are working well with FUA.

I am OK with attempting enabling FUA by default for the following reasons:
1) The vast majority of drives in libata blacklist (all features) are
old models that are not sold anymore.
2) We are restricting FUA support to drives that also support NCQ, that
is, modern-ish ones that are supposed to process the FUA NCQ read/write
commands correctly, per specs.
3) For HDDs, which is the vast majority of ATA devices out there these
days, all recent drives I have tested are OK. Even older ones with NCQ
support that I have access to are fine.
4) We are at rc2, which gives us time to revert patch 7 if we see too
many bug reports.

One thing we could add to the patch series is an additional restriction
to enabling FUA by default to drives that support a recent standard. Say
ACS-4 and above. That will restrict this to recent devices, thus
reducing the risk of hitting bad apples. Thoughts ?

-- 
Damien Le Moal
Western Digital Research