On Thu, Feb 25, 2021 at 09:34:47AM +0100, Christoph Hellwig wrote:

On Thu, Feb 25, 2021 at 08:44:17AM +1100, Dave Chinner wrote:

quoted

quoted

Also, do you have any idea what was Christoph talking about wrt devices
with no-op flushes the last time this patch was posted?  This change
seems straightforward to me (assuming the answers to my two question are
'yes') but I didn't grok what subtlety he was alluding to...?

He was wondering what devices benefited from this. It has no impact
on highspeed devices that do not require flushes/FUA (e.g. high end
intel optane SSDs) but those are not the devices this change is
aimed at. There are no regressions on these high end devices,
either, so they are largely irrelevant to the patch and what it
targets...

I don't think it is that simple.  Pretty much every device aimed at
enterprise use does not enable a volatile write cache by default.  That
also includes hard drives, arrays and NAND based SSDs.

Especially for hard drives (or slower arrays) the actual I/O wait might
matter.  What is the argument against making this conditional?

I still don't understand what you're asking about here --

AFAICT the net effect of this patchset is that it reduces the number of
preflushes and FUA log writes.  To my knowledge, on a high end device
with no volatile write cache, flushes are a no-op (because all writes
are persisted somewhere immediately) and a FUA write should be the exact
same thing as a non-FUA write.  Because XFS will now issue fewer no-op
persistence commands to the device, there should be no effect at all.

In contrast, a dumb stone tablet with a write cache hooked up to SATA
will have agonizingly slow cache flushes.  XFS will issue fewer
persistence commands to the rock, which in turn makes things faster
because we're calling the engravers less often.

What am I missing here?  Are you saying that the cost of a cache flush
goes up much faster than the amount of data that has to be flushed?

--D