On Mon, Jan 2, 2012 at 21:28, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> On Mon, Jan 2, 2012 at 21:14, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> I'm wondering what's your basis for asserting we don't support CIFS in
>>> general? =A0It'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. =A0I 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. =A0Just looking at the standard's description of fsync's error
> conditions:
>
> =A0 =A0 =A0 =A0The fsync() function shall fail if:
> =A0 =A0 =A0 =A0[EBADF]
> =A0 =A0 =A0 =A0The fildes argument is not a valid descriptor.
> =A0 =A0 =A0 =A0[EINTR]
> =A0 =A0 =A0 =A0The fsync() function was interrupted by a signal.
> =A0 =A0 =A0 =A0[EINVAL]
> =A0 =A0 =A0 =A0The fildes argument does not refer to a file on which this=
operation is possible.
> =A0 =A0 =A0 =A0[EIO]
> =A0 =A0 =A0 =A0An 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. =A0So 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=3Don? It
basically means fsync=3Dmaybe, no?
--=20
=A0Magnus Hagander
=A0Me: http://www.hagander.net/
=A0Work: http://www.redpill-linpro.com/
