On Wed, Feb 08, 2006 at 02:49:06PM -0500, Daniel Berlin wrote:
> On Wed, 2006-02-08 at 16:18 +0100, Folker Schamel wrote:
> > Why isn't it the only valid behaviour that the transaction is cancelled
> > if there is a disk write error?
> It is.
>
> Note that this is why it is buggy :)
>
> We're just not sure *where* this is happening.
>
I think Folker may have been asking why FSFS doesn't enforce that
behaviour by marking the transaction as doomed when it sees a disk write
error, rather than assuming that the caller will do it. And he's right,
it should.
The main reasons I hadn't gone down that path already are (as I wrote
originally): a) that APR <= 0.9.6 doesn't report those errors anyway,
and b) that I thought that adding code to check explicitly for EIO on
every write would be unacceptably unmaintainable.
However, now I come to think of it, the approach I have been thinking
about (to ensure that the file handles don't remain open on error)
should be extensible to killing the transaction on error as well,
without a great deal of difficulty or extra invasiveness.
(Another problem I've just noticed is that APR doesn't actually seem to
provide any way to check for EIO returns, so I think we'd probably have
to just treat any 'unexpected' error as a dooming error.)
If I do get around to doing the former, I'll certainly look at the latter
as well.
Regards,
Malcolm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Feb 9 18:02:10 2006