3:15 a.m.
The application doing "create a temp file, write some data, close the the
file, then rename" should be doing in that order. In other words, it has to
wait at least for the temp file creation before sending rename.
Linux NFS client does cache attributes by default. It should manipulate and
do the right things, if the writes are cached. Can you simulate what
Netezza is doing in a small program or script and recreate it? Mount option
"-onoac" or "-osync" may help but would like to understand this issue
further as file size should be consistent if viewed from the same NFS
client.
On Mon, Oct 7, 2019 at 7:18 PM Daniel Gryniewicz <dang(a)redhat.com> wrote:
A couple of questions to begin with. What NFS version are you
mounting?
I assume this is a Linux client?
NFS is an asynchronous protocol. That is, no two ops that are not in
the same compound have any guaranteed ordering with respect to each
other. This is one of the reasons that NFSv4 introduced compounds: to
guarantee such ordering. The client can get correct ordering by waiting
for the reply to the first op before sending the second op, but if the
second op arrives while the first op is being processed, it's perfectly
fine for the second op to return to the client before the first op.
My guess is that you have the client mounted with the async flag. This
causes the kernel to return success on write to the application before
it's actually sent the data to the server. It sends the write op in the
background, but this means that, even if the app waits for the write to
"complete", there's no guarantee that the write has been sent to the
server yet. If this is the case, mount your filesystem sync, and this
should fix it.
Daniel
On 10/4/19 8:47 PM, Satish Chandra Kilaru wrote:
> Hi All,
>
> I am using nfs-ganesha 2.6.3. I am dumping Netezza to a Linux machine
running nfs-ganesha. Netezza writes data in 1MB chunks. After each write it
checks size of file. After dumping some data it failed saying that expected
size is 106MB. But the file size is 104MB.
> Nfs-Ganesha debug logs indicated that one of the workers processed a
getattr RPC (supposed to have been sent after writing 104MB) after
receiving write RPC for 106MB but before it was written to disk.
>
> Is this valid behavior from nfs-ganesha? Are there any settings (on
nfs-client or on nfs-ganesha) to make sure operations on a given file are
processed in the order they are received?
>
> I have seen another weird problem. I have not got a chance to check logs
for it yet. My application creates a temp file, writes small data (10K) to
it, closes the file and then renames it. This rename failed with ENOEXIST.
I see that temp file is indeed present. Based on my observation with
Netezza I am suspecting that that rename was processed before the temp file
create RPC was processed. Could that be possible?
>
> --Satish
> --Satish
> _______________________________________________
> Devel mailing list -- devel(a)lists.nfs-ganesha.org
> To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org
>
_______________________________________________
Devel mailing list -- devel(a)lists.nfs-ganesha.org
To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org