Re: fsync error reporting

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> (3) I think the drawbacks of reporting user 1's I/O errors to user 2
> [...] mean that we should guarantee that I/O errors from *your*
> writes should be reported by *your* call to fsync.  [...]

> (3a) I don't think it's necessary to guarantee that I/O errors from
> other people's writes won't _also_ be reported by your fsync call,
> but I think any natural implementation that supports the prior
> guarantee will also have this property.

I'm not so sure.

A opens F
B opens F
A write()s 10 bytes at offset 10, thereby dirtying the block at offset 0
B write()s 10 bytes at offset 30, thereby dirtying the block at offset 0
Kernel now pushes the block at offset 0 and gets a hardware error

Now: which of the writes errored and thus should get an error at next
fsync?  A's?  B's?  Both?  If B's write is instead at offset 10, so it
completely overwrites A's, does that change your answer?

I think the only sane answer to the first question is "both".  This
then leaves open the question of how to ensure _both_ fsync()s error.
I don't see any particularly "natural" way to do that that won't also
report errors due to someone else's write.  Maybe I'm just missing
something.

> (6) We do absolutely need to guarantee that when fsync returns
> everything that process wrote is on disk,

That is probably unattainable, since I've seen it plausibly asserted
that some disks lie, reporting that writes are on the media when this
is not actually true.

However, I think the kernel can be excused for believing a lie from the
device in that regard, especially since there really isn't much
alternative.

> (8) I'm not convinced that there's any real value in reporting
> exactly what blocks failed.

Is there any interface to do so via?

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B