All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Phil Endecott" <phil_bnaqb_endecott-wZDNlLIRyE5g9hUCZPvPmw@public.gmane.org>
To: <linux-nfs@vger.kernel.org>
Subject: Propagation of changes in shared mmap()ed NFS files
Date: Sat, 21 Jun 2008 20:05:20 +0100	[thread overview]
Message-ID: <1214075120367@dmwebmail.dmwebmail.chezphil.org> (raw)

Dear Experts,

I have a program which uses an mmap()ed read-mostly data file.  When 
not using NFS, each instance of the program can use inotify to detect 
when other instances have made changes to the data file.  Since inotify 
doesn't work with NFS, I have now implemented a scheme using network 
broadcasts to announce changes.  At present it works like this:

All instances of the program mmap(MAP_SHARED) the data file.

One instance stores some new data at the end of the file and calls 
msync(MS_SYNC) on the affected pages.  It then "atomically commits" the 
new data by write()ing a new header at the start of the file with an 
"end of data" field advanced to include the new data.  It then calls 
fdatasync().  Then it transmits a broadcast packet.

The other instance(s) of the program receive the broadcast packet and 
read() the header at the start of the file.  My hope was that they 
would see the new value, but they don't; they continue to see the old value.

In order to allow for network broadcasts being unreliable the 
wait-for-broadcast code has a 30 second timeout; when this timeout next 
expires the program reads the header again and now it sees the new 
end-of-data offset, and the new data in the mapped memory region.

So, what do I have to do so that the new data is visible promptly?  Is 
there more that the sender or the receiver should do to tell the local 
kernel or the NFS server to propagate changes?  For example, does 
msync(MS_INVALIDATE) do anything useful?  Do I simply have to wait for 
some delay after receiving the broadcast?

I have also observed that when the changes are finally noticed, it 
seems that the whole of the multi-megabyte file is re-fetched from the 
server as it is accessed, despite only a few hundred bytes having 
changed.  This is undesirable; is there anything that I can do to 
prevent it?  (I tried calling mlock(), mainly to check that this wasn't 
a memory-pressure problem, but it still seems to re-fetch it.)

Ideally I'd like to have something that will work with any non-ancient 
version of NFS, and perhaps even CIFS too, but for now I'd be happy 
with getting it working on this nfsv3 system.

Many thanks for any advice,

Phil.





             reply	other threads:[~2008-06-21 19:34 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-21 19:05 Phil Endecott [this message]
     [not found] ` <1214075120367-YnoLgZYwwYuCbKHnblo0pmrPP3OPMK55cpQHUIT47Ck@public.gmane.org>
2008-06-21 21:43   ` Propagation of changes in shared mmap()ed NFS files Trond Myklebust
2008-06-21 22:02     ` Phil Endecott
     [not found]       ` <1214085757714-YnoLgZYwwYuCbKHnblo0pmrPP3OPMK55cpQHUIT47Ck@public.gmane.org>
2008-06-21 22:12         ` Trond Myklebust
2008-06-22 12:09           ` Phil Endecott

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1214075120367@dmwebmail.dmwebmail.chezphil.org \
    --to=phil_bnaqb_endecott-wzdnllirye5g9huczpvpmw@public.gmane.org \
    --cc=linux-nfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.