Hi Tom, Thanks for the solution. CIFS worked with fsync flag by ingnoring EINVAL in copydir.c. I tested fsync with 8.2.2 version of PostgreSQL, it worked fine without EINVAL patch. I wanted to know is something changed in version 9.0.4 of postgreSQL. As fsync flag was not working with PostgreSQL version 9.0.4 without applying the patch. Regards, Anjali
________________________________ From: Magnus Hagander <mag...@hagander.net> To: Tom Lane <t...@sss.pgh.pa.us> Cc: anjali_...@yahoo.co.in; pgsql-bugs@postgresql.org Sent: Tuesday, 3 January 2012 2:00 AM Subject: Re: [BUGS] BUG #6372: Error while creating database with fsync parameter as on incase of CIFS 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/
