On 21.04.25 17:41, Eric Blake wrote:
On Mon, Apr 21, 2025 at 09:15:33AM +0300, Vladimir Sementsov-Ogievskiy wrote:
On 17.04.25 00:51, Eric Blake wrote:
(a write zeroes that fails AND causes the disk to no longer read as
zero should not happen)
I don't know, is there such a contract? write-zeroes may fallback to write(),
which only state that:
An error return value while performing write() using direct I/O
does not mean the entire write has failed. Partial data may be
written and the data at the file offset on which the write() was
attempted should be considered inconsistent.
So, I used to think that on failed write nothing is guaranteed.
What do we lose if we just unset the bitmap before write-zeroes, and set it
again in case of success?
I still don't see the point. Either the cluster was already non-zero
before the failed write-zero (so there's no bit to pre-clear);
[..]
cluster was already zero before the failed write-zero, and any failure
that corrupts the disk by actually turning zeroes into non-zero
Yes, I mean this case
is not
worth worrying about
And I don't follow why we should not care.
Usually we have no assumptions about data at offset, if write(offset, ..)
failed. We just retry write.
Here we do this assumption "if there were zeroes, they will not be broken by writing
zeroes even on failure scenarios", for any kind of block-driver and underlying file
system.
You say "corrupts the disk". Of course, if disk is corrupted - everything is
broken, and we should not care. The result of the mirror would be incorrect anyway. But
we don't consider any EIO as disk corruption. We do retry the write and continue mirror
operation.
Moreover, if EIO is returned due to some broken sector, we may hope that
retrying the write will fix it, probably some other sector will be allocated by
FS (I hope I'm not talking nonsense). But relying on the data still read as
zero without rewriting would be wrong.
, so pre-clearing the bit is not going to make
things any better.
--
Best regards,
Vladimir
