forcing an nfs sync - NFS

This is a discussion on forcing an nfs sync - NFS ; I'm occasionally polling over nfs for the appearance of a file on my remote server. I'm running asynchronously, as I understand it's more efficient. However, sometimes there is a considerable lag between the time the file is created remotely and ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: forcing an nfs sync

  1. forcing an nfs sync

    I'm occasionally polling over nfs for the appearance of a file on my
    remote server. I'm running asynchronously, as I understand it's more
    efficient. However, sometimes there is a considerable lag between the
    time the file is created remotely and it's seen locally (makes sense).

    Since I poll only occasionally, I don't want the cost of a synchronous
    setup. Is there a convenient way to force the remote nfs server to sync,
    before I test for the existence of the file locally? I am looking for a
    linux command or a way to do it in "C". Thanks. Neall

  2. Re: forcing an nfs sync

    On Mon, 10 Oct 2005 14:45:36 -0600, Linux Doctor wrote:

    >I'm occasionally polling over nfs for the appearance of a file on my
    >remote server. I'm running asynchronously, as I understand it's more
    >efficient. However, sometimes there is a considerable lag between the
    >time the file is created remotely and it's seen locally (makes sense).


    Not make any sense to me, I use the sync option in /etc/exports, if
    I download a file to the server, that file is immediately known to
    localnet clients with that export mounted. I've not noticed any lag.

    >Since I poll only occasionally, I don't want the cost of a synchronous
    >setup. Is there a convenient way to force the remote nfs server to sync,
    >before I test for the existence of the file locally? I am looking for a
    >linux command or a way to do it in "C". Thanks. Neall


    What differences does your benchmarking tell you? What's the cost?

    Grant.

  3. Re: forcing an nfs sync


    See interleaved comments...

    On Tue, 11 Oct 2005 at 11:18am, Grant scribbled:

    > On Mon, 10 Oct 2005 14:45:36 -0600, Linux Doctor wrote:
    >
    >> I'm occasionally polling over nfs for the appearance of a file on my
    >> remote server. I'm running asynchronously, as I understand it's more
    >> efficient. However, sometimes there is a considerable lag between the
    >> time the file is created remotely and it's seen locally (makes sense).

    >
    > Not make any sense to me, I use the sync option in /etc/exports, if
    > I download a file to the server, that file is immediately known to
    > localnet clients with that export mounted. I've not noticed any lag.


    Follow-up from original poster (me):

    I used the sync option in the /etc/exports file of the server, along with
    no_wdelay, and clients still didn't see immediate changes in the file on
    the server. There was a definite lag (several seconds typically, if not
    more).

    Apparently, the server was syncing immediately as a result, but not the
    clients. What I ended up having to do was to add a actimeo option to the
    mount command (/etc/fstab) on the CLIENT side. This resolved the issue.

    >> Since I poll only occasionally, I don't want the cost of a synchronous
    >> setup. Is there a convenient way to force the remote nfs server to sync,
    >> before I test for the existence of the file locally? I am looking for a
    >> linux command or a way to do it in "C". Thanks. Neall

    >
    > What differences does your benchmarking tell you? What's the cost?


    In my application, I don't have a lot of NFS traffic, but need to know
    quickly about changes in the files on the server. My tests showed that
    "sync" did not affect the overall throughput (as opposed to async), at
    least in my application. The massive amount of literature online seems to
    indicate that there is a cost with using "sync," but it's obviously
    application dependent and I didn't see any pentalty at all. Neall

    > Grant.
    >


  4. Re: forcing an nfs sync

    Hi Neall,
    On Tue, 11 Oct 2005 09:15:24 -0600 (MDT), Linux Doctor wrote:

    Search lkml.org for "Cache invalidation bug in NFS v3 - trivially reproducible"
    came up yesterday, might be something? (linux kernel mailing list)

    >Follow-up from original poster (me):
    >
    >I used the sync option in the /etc/exports file of the server, along with
    >no_wdelay, and clients still didn't see immediate changes in the file on
    >the server. There was a definite lag (several seconds typically, if not
    >more).
    >
    >Apparently, the server was syncing immediately as a result, but not the
    >clients. What I ended up having to do was to add a actimeo option to the
    >mount command (/etc/fstab) on the CLIENT side. This resolved the issue.


    Okay, I have simple setup:

    server:
    / 192.168.1.0/24(sync,rw,no_root_squash)
    /home/share 192.168.1.0/24(sync,rw,no_root_squash)
    /home/mirror 192.168.1.0/24(sync,ro)

    client:
    deltree:/ /home/deltree nfs noauto,user,hard,intr
    deltree:/home/mirror /home/mirror nfs hard,intr
    deltree:/home/share /home/share nfs hard,intr

    I do linux-kernel testing, each target machine mounts /home/share,
    from where they pickup latest kernel source and patches. I've never
    noticed a lag from getting a new patch and being able to pick it
    up from clients. Likewise, on each client reboot I write dmesg and
    config to the server's /home/share, on server I move those files to
    appropriate machine web page .

    >
    >In my application, I don't have a lot of NFS traffic, but need to know
    >quickly about changes in the files on the server. My tests showed that
    >"sync" did not affect the overall throughput (as opposed to async), at
    >least in my application. The massive amount of literature online seems to
    >indicate that there is a cost with using "sync," but it's obviously
    >application dependent and I didn't see any pentalty at all. Neall


    Okay, I think that's the point I was trying to make, reliability before
    speed? I have NFS 3 over TCP enabled, no ACLs, no selinux, as there's no
    hostile user-base here (unless I'm in a bad mood ) Reiserfs, if that
    makes a difference. Server runs 2.4.31-hf6, clients run 2.4 or 2.6 latest
    or development. All are Slackware 10.1 or later.

    Cheers,
    Grant.


  5. Re: forcing an nfs sync

    As I understand it, "sync" has nothing to do with it.

    "sync" is to instruct the server to commit the WRITEs to stable
    storage. Using "sync" and "async" shouldn't make any difference (other
    than write speed) unless your server crashes.

    Now, suppose host A is writing (async) to server. The WRITE data is in
    the server's caches, just not on disk. So when host B polls, B should
    see the new data.

    If you want to make host B see the new data sooner, you may need to use
    the "actimeo" mount option. In NFS, a client may decide to cache a
    file's attributes locally. So even though your application polls every
    second, it doesn't mean that the NFS client contacts the server every
    second.

    bc


  6. Re: forcing an nfs sync

    On Sat, 15 Oct 2005 at 12:10am, bcwalrus scribbled:

    > If you want to make host B see the new data sooner, you may need to use
    > the "actimeo" mount option. In NFS, a client may decide to cache a
    > file's attributes locally. So even though your application polls every
    > second, it doesn't mean that the NFS client contacts the server every
    > second.


    Exactly right. using actimeo fixed the problem. Thanks. Neall


+ Reply to Thread