Re: BUG #6372: Error while creating database with fsync parameter as on incase of CIFS

On Mon, Jan 2, 2012 at 21:28, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>> On Mon, Jan 2, 2012 at 21:14, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> I'm wondering what's your basis for asserting we don't support CIFS in
>>> general?  It's probably not terribly bulletproof, but any worse than NFS?
>
>> Yes, it is a lot worse than NFS from experience. I can't find a
>> reference to it anywhere now, but IIRC there are bigger issues - with
>> blocksizes, with syncing not properly, with write ordering.
>
> Hmm.  I searched the list archives and couldn't find any previous
> discussion of such things, but that may just prove that no one thinks
> it's worth attempting.

Yeah, I don't think it was in our archives, it was somewhere else.

And as a disclaime r- it may have been about the win32 cifs *client*.
It was at the time just talking windows cifs client -> windows cifs
server.

> Anyway the immediate question is which errnos are reasonable for copydir
> to ignore.  Just looking at the standard's description of fsync's error
> conditions:
>
>        The fsync() function shall fail if:
>        [EBADF]
>        The fildes argument is not a valid descriptor.
>        [EINTR]
>        The fsync() function was interrupted by a signal.
>        [EINVAL]
>        The fildes argument does not refer to a file on which this operation is possible.
>        [EIO]
>        An I/O error occurred while reading from or writing to the file system.
>
> it seems like EINVAL is a considerably more reasonable thing to return
> than EBADF, if the filesystem is trying to tell you that it won't fsync
> a directory.  So I'm a bit surprised this question hasn't come up for
> other filesystems.

Agreed. But do we really want to accept this with fsync=on? It
basically means fsync=maybe, no?

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/