Linux NFS fsync problems

Hi,
I have an NFS mount from a linux client to a linux NFS server using a
soft mount.

I have a program that is writing to a file on that share, correctly
checking for return values and after each write calls fsync. It also
logs each message with a unique increasing transaction ID.

When I reboot my NFS server, my client application does not see any
error and fsync continues to return success. When the NFS server
comes back up, the writes keep going through, but all the writes that
were issued while the NFS server was down is lost.

How do I detect that the writes are actually NOT succeeding?

In news:efd6663a-8305-40ef-a5d5-(E-Mail Removed),
(E-Mail Removed) <(E-Mail Removed)> typed:

> I have an NFS mount from a linux client to a linux NFS server using a
> soft mount.
>
> I have a program that is writing to a file on that share, correctly
> checking for return values ....
>
> When I reboot my NFS server, my client application does not see any
> error and fsync continues to return success. When the NFS server
> comes back up, the writes keep going through, but all the writes that
> were issued while the NFS server was down is lost.

Obviously, the program that is "correctly checking for return values" isn't.

On Apr 30, 1:36 pm, "h.stroph" <m...@privacy.net> wrote:
> Innews:efd6663a-8305-40ef-a5d5-(E-Mail Removed),
> byaa...@yahoo.com <byaa...@yahoo.com> typed:
>
> > I have an NFS mount from a linux client to a linux NFS server using a
> > soft mount.
>
> > I have a program that is writing to a file on that share, correctly
> > checking for return values ....
>
> > When I reboot my NFS server, my client application does not see any
> > error and fsync continues to return success. When the NFS server
> > comes back up, the writes keep going through, but all the writes that
> > were issued while the NFS server was down is lost.
>
> Obviously, the program that is "correctly checking for return values" isn't.

No, it is, since it behaves correctly against other systems, like a
NetApp. It's a pretty simple program that does a pwrite and an fsync.

In news:96f0543f-cdd0-4606-b586-(E-Mail Removed),
(E-Mail Removed) <(E-Mail Removed)> typed:

>>> I have a program that is writing to a file on that share, correctly
>>> checking for return values ....
>>
>>> When I reboot my NFS server, my client application does not see any
>>> error and fsync continues to return success. When the NFS server
>>> comes back up, the writes keep going through, but all the writes
>>> that were issued while the NFS server was down is lost.
>>
>> Obviously, the program that is "correctly checking for return
>> values" isn't.
>
> No, it is, since it behaves correctly against other systems, ...

Ah, that's why it's telling you that the NFS writes are successful when the
NFS server is down ... you're using a different definition of the concept
"correctly checking."

On Apr 30, 3:55 pm, "h.stroph" <m...@privacy.net> wrote:
> Innews:96f0543f-cdd0-4606-b586-(E-Mail Removed),
> byaa...@yahoo.com <byaa...@yahoo.com> typed:
>
> >>> I have a program that is writing to a file on that share, correctly
> >>> checking for return values ....
>
> >>> When I reboot my NFS server, my client application does not see any
> >>> error and fsync continues to return success. When the NFS server
> >>> comes back up, the writes keep going through, but all the writes
> >>> that were issued while the NFS server was down is lost.
>
> >> Obviously, the program that is "correctly checking for return
> >> values" isn't.
>
> > No, it is, since it behaves correctly against other systems, ...
>
> Ah, that's why it's telling you that the NFS writes are successful when the
> NFS server is down ... you're using a different definition of the concept
> "correctly checking."

Apparently this is a known issue in the Linux NFS implementation...
Thanks for the hep.