Re: [PATCH v2] scsi: target: Allow FUA if no write cache enabled

[stuart hayes <stuart.w.hayes@gmail.com>]

On 4/30/2026 10:43 AM, Martin K. Petersen wrote:
> 
> Stuart,
> 
>> Without this patch, accesses with FUA set will be rejected, even
>> though they always go directly to the media when there's no write
>> cache.
> 
> The spec allows this. However, ...
> 
>> This is needed because EDK2 FAT filesystem code sets the FUA bit when
>> writing, regardless of whether the device advertises support of
>> DPOFUA.
> 
> ^^^ that is clearly a spec violation. What is being done to address this
> issue?
> 
I've gone through SBC and SPC, and I can't find anything that would 
suggest that this is a spec violation.

And, not that what I think makes any difference, but I don't see the 
point in requiring an initiator to check DPOFUA before setting FUA on a 
write that needs to go straight to media... why not just set FUA 
whenever needed, and if the FUA bit wasn't strictly required to ensure 
that the write went straight to media, who cares, if the requested 
behavior is still provided?

> Also, wrt. the patch itself, please see:
> 
> https://sashiko.dev/#/patchset/20260428203938.9738-1-stuart.w.hayes%40gmail.com
> 
The AI review suggests moving this fix to sbc_check_dpofua(), so that 
DPOFUA behavior in the mode page is unchanged, and it just silently 
allows writes with FUA set even if DPOFUA isn't set.

If there's no objection, I'll submit a new patch that does that. The 
reason I didn't do that the first time around is that it breaks some of 
the blktests that specifically check to make sure a command fails if FUA 
is set when DPOFUA isn't.