Re: [PATCH 2/2] scsi: ufs: Use SYNCHRONIZE CACHE instead of FUA

[James Bottomley <jejb@linux.ibm.com>]

On Thu, 2023-02-02 at 11:00 -0800, Bart Van Assche wrote:
> On 2/2/23 10:46, James Bottomley wrote:
> > Well, that may not be true in all situations.  Semantically FUA is
> > a barrier: it can be implemented such that it destages only the
> > current write plus the cache writes that occurred before the write
> > with the FUA.  It could also be implemented as you suggest above,
> > which simply destages the entire cache, but it doesn't have to be. 
> > One of the reasons for FUA to exist is the potential difference
> > between the two.
> 
> Hi James,
> 
> Although support for the barrier concept has been removed from the
> block layer, would it be possible to tell me in which T10 document I
> can find  more information about the barrier semantics? All I found
> in the latest  SBC-5 draft (revision 4; 2023-01-24) about FUA is the
> following (section 5.40 WRITE (10)):

I have only a vague recollection of manufacturers implementing this
semantic but ...

> "A force unit access (FUA) bit set to one specifies that the device 
> server shall write the logical blocks to:
> a) the non-volatile cache, if any; or
> b) the medium.
> An FUA bit set to zero specifies that the device server shall write
> the logical blocks to:
> a) volatile cache, if any;
> b) non-volatile cache, if any; or
> c) the medium."
> 
> To me the description of FUA in the SBC-3 draft from 11 November 2013
> seems identical to the above text.

So what that says is the FUA write writes to the medium and *doesn't*
flush the volatile cache (so any writeback data stays there).  I assume
this style is for metadata reservations, so we guarantee fs tree
consistency but not necessarily file data consistency.  However, that
makes flushing everything a way bigger hammer than this behaviour.

James