From: "Phil Endecott" <phil_bnaqb_endecott-wZDNlLIRyE5g9hUCZPvPmw@public.gmane.org>
To: "Trond Myklebust" <trond.myklebust@fys.uio.no>
Cc: <linux-nfs@vger.kernel.org>
Subject: Re: Propagation of changes in shared mmap()ed NFS files
Date: Sat, 21 Jun 2008 23:02:37 +0100 [thread overview]
Message-ID: <1214085757714@dmwebmail.dmwebmail.chezphil.org> (raw)
In-Reply-To: <1214084624.7493.0.camel@localhost>
Trond Myklebust wrote:
> On Sat, 2008-06-21 at 20:05 +0100, Phil Endecott wrote:
>> 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.
>
> open(O_DIRECT) is your friend.
Thanks Trond, I'll give it a try.
This only affects the write()s and read()s though, doesn't it? So are
you suggesting that the mmap()ed data is correctly propagated already,
and only the write-to-read needs fixing?
BTW the man page is a bit discouraging about the combination of
O_DIRECT and mmap(): "applications should avoid mixing mmap(2) of files
with direct I/O to the same files." Fingers crossed....
Phil.
next prev parent reply other threads:[~2008-06-21 22:02 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-21 19:05 Propagation of changes in shared mmap()ed NFS files Phil Endecott
[not found] ` <1214075120367-YnoLgZYwwYuCbKHnblo0pmrPP3OPMK55cpQHUIT47Ck@public.gmane.org>
2008-06-21 21:43 ` Trond Myklebust
2008-06-21 22:02 ` Phil Endecott [this message]
[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=1214085757714@dmwebmail.dmwebmail.chezphil.org \
--to=phil_bnaqb_endecott-wzdnllirye5g9huczpvpmw@public.gmane.org \
--cc=linux-nfs@vger.kernel.org \
--cc=trond.myklebust@fys.uio.no \
/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.