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

Hi Tom,
=A0
Thanks for the solution. CIFS worked with fsync flag by=A0ingnoring EINVAL =
in copydir.c.=20
=A0
I tested fsync with 8.2.2 version of PostgreSQL, it worked fine without EIN=
VAL patch. I wanted to know is something changed in version 9.0.4 of postgr=
eSQL.
=A0
As=A0fsync flag=A0was not working with PostgreSQL version 9.0.4 without app=
lying the patch.
=A0
Regards,
Anjali
=20

________________________________
 From: Magnus Hagander <magnus@hagander.net>
To: Tom Lane <tgl@sss.pgh.pa.us>=20
Cc: anjali_524@yahoo.co.in; pgsql-bugs@postgresql.org=20
Sent: Tuesday, 3 January 2012 2:00 AM
Subject: Re: [BUGS] BUG #6372: Error while creating database with fsync par=
ameter as on incase of CIFS
=20
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/=