On Mon, Dec 09, 2024 at 05:18:00PM +0900, Damien Le Moal wrote: > > Yep. But even that one is actually coded in scsi to return a -EIO instead of > ENOTSUPP. We can patch that (return ENOTSUPP for an invalid opcode error), > but I > am not sure if that is safe to do given that this has been like this for ages. > > This is all to say that we cannot even reliably distinguish special/valid > error > cases that can be recovered from actual medium/hard errors.
I think we can't change the return value, as the whole thing is messy. I just meant EOPNOTSUP-like. The exact error should not matter for the handling anyway, just reasoning about use cases. > I have test cases for zonefs already. That is because zonefs has the > "recover-error" mount option which forces a recovery of a file size (== write > pointer position) if a write fails or is torn. The default even for zonefs is > to > go read-only since there is indeed not much we can do about failed writes. Yes, that іs the sensible way to handle errors as far as I'm conerned.
