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

[Tejun Heo <tj@kernel.org>]

Hello,

On Fri, Jan 06, 2023 at 03:51:48PM +0900, Damien Le Moal wrote:
> OK. Granted. But for this particular case, scsi & nvme subsystem do not
> treat FUA as "optional". If it is supported, it will be used even though
> you are correct that we can work without it. I do not think we should
> treat ATA devices any differently.

What matters isn't that they have a featured with the same name but the
actual circumstances. e.g. for nvme, FUA has been there from the beginning
and we used it from the beginning so we know that they're safe. For ATA,
it's something added later on and we know that there are a bunch of devices
which choke on it and we don't know whether anyone else is using it at any
scale.

> > On a quick glance, there are some uses of REQ_FUA w/o REQ_PREFLUSH which
> > indicates that there can be actual gains to be had. However, ext4 AFAICS
> > always pairs PREFLUSH w/ FUA, so a lot of use cases won't see any gain while
> > taking on the possible risk of being exposed to FUA commands.
> 
> Yes. Most FSes will do PREFLUSH | FUA. For the risk, see above.

Someone should benchmark it but it's likelyt that PREFLUSH | FUA vs.
PREFLUSH | WRITE | POSTFLUSH isn't gonna show any meaningful difference in
any realistic scenario. The main gain of NCQ'd FUA is that we don't have to
drain the in-flight commands but PREFLUSH needs that anyway.

> > I feel rather uneasy about enabling FUA by default given history. We can
> > improve its chances by restricting it to newer devices and maybe even just
> > hard disks, but it kinda comes back to the root question of why. Why would
> > we want to do this? What are the benefits? Right now, there are a bunch of
> > really tricky cons and not whole lot on the pro column.
> 
> OK. But again, why treat ATA devices differently from scsi/nvme/ufs ?
> These have FUA used by default if it is supported.

This part hopefully is answered above.

> We can take a big hammer here and start with enabling only ACS-5 and
> above for now. That will represent the set of devices that are in
> development right now, and only a few already released (I have some in
> my test boxes and they are not even a few months old...).

All that said, yeah, if we restrict it to only the newest devices, they're
more likely to be well behaved and a lot more visible when they misbehave.
That sounds reasonable to me.

Thanks.

-- 
tejun