Re: fsync fails on O_RDONLY file handle (patch attached)

On Wed, Feb 08, 2006 at 04:35:35PM -0500, Mike Ashmore wrote:
> Unfortunately, Malcolm's patch still doesn't fix STOP. Using strace,
> it looks like the problem occurs when you open("<repository>/db/
> revprops", O_RDONLY). The fsync immediately after that operation fails.
>

Okay. I'm not entirely surprised, though it seems odd that STOP provides
a close-enough Linux ABI to define __linux__, but not one that supports
the well-known mechanism for flushing directory modifications to disk.

I presume that prior to this patch, the fsync that failed was the one
sync-ing the revision file (/db/revs/0)? If so, I'll commit the patch
I provided anyway - it does make sense by itself.

What error does fsync() return in the failing case? (syncing the
directory) I suppose we could ignore EROFS or EINVAL, or possibly even
EBADF, since those errors don't really indicate a failure to sync the
directory per se (that would be EIO, I think), more an inability to sync
a directory in the first place, which isn't something we should fail on.

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 14:12:11 2006