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
