On Mon, Jan 2, 2012 at 21:28, Tom Lane <t...@sss.pgh.pa.us> wrote: > Magnus Hagander <mag...@hagander.net> writes: >> On Mon, Jan 2, 2012 at 21:14, Tom Lane <t...@sss.pgh.pa.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/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
