On 1/9/25 9:07 PM, Damien Le Moal wrote:
On 1/10/25 04:11, Bart Van Assche wrote:
On 11/18/24 6:57 PM, Damien Le Moal wrote:
And we also have the possibility of torn writes (partial writes) with
SAS SMR drives. So I really think that you cannot avoid doing a
report zone to recover errors.
(replying to an email of two months ago)
Hi Damien,
How about keeping the current approach (setting the
BLK_ZONE_WPLUG_NEED_WP_UPDATE flag after an I/O error has been observed)
if write pipelining is disabled and using the wp_offset_compl approach
only if write pipelining is enabled? This approach preserves the
existing behavior for SAS SMR drives and allows to restore the write
pointer after a write error has been observed for UFS devices. Please
note that so far I have only observed write errors for UFS devices if I
add write error injection code in the UFS driver.
If you get write errors, they will be propagated to the user (f2fs in this case
I suspect) which should do a report zone to verify things. So I do not see why
this part would need to change.
Hi Damien,
In my email I was referring to write errors that should *not* be
propagated to the user but that should result in a retry by the kernel.
This is e.g. necessary if multiple writes are outstanding simultaneously
and the storage device reports a unit attention condition for any of
these writes except the last write.
Thanks,
Bart.
