From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Marcelo Tosatti <marcelo@conectiva.com.br>
Cc: Andrea Arcangeli <andrea@suse.de>, Kurt Garloff <garloff@suse.de>,
Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: nfs MAP_SHARED corruption fix
Date: Thu, 10 May 2001 12:11:35 +0200 [thread overview]
Message-ID: <15098.26967.99796.538394@charged.uio.no> (raw)
In-Reply-To: <Pine.LNX.4.21.0105092045410.15984-100000@freak.distro.conectiva>
In-Reply-To: <20010510031652.G2506@athlon.random> <Pine.LNX.4.21.0105092045410.15984-100000@freak.distro.conectiva>
>>>>> " " == Marcelo Tosatti <marcelo@conectiva.com.br> writes:
> I suggested the removal of I_DIRTY_PAGES check because the
> current behaviour of munmap seems to be synchronous (1), so I
> guess you _always_ want it to be synchronous.
Yes. The NFS concept of close-to-open cache consistency requires you
to flush out all writes upon file close(). In this case, the usual
nfs_wb_file() + error reporting in nfs_release() won't catch anything
that's been put out using writepage(), because the latter can't mark
the requests using the struct file. This means we have to do something
special for mmap...
>> Another thing (completly unrelated to the above issues) that I
>> noticed while looking over this nfs code is that the
>> __sync_one() for example called by generic_file_write(O_SYNC)
>> will recall fdatasync but no nfs_wb_all is put before the
>> fdatawait, and I'm not sure that the nfs_sync_page called by
>> the fdatawait is enough to rapidly flush the writepaged stuff
>> to the nfs server. nfs_sync_page apparently only cares about
>> speculative reads, not at all about committing writebacks. It
>> would look much saner to me if nfs_sync_page also does a
>> nfs_wb_all() on the inode, so that the ->sync_page callback
>> gets the same semantics it has for the real filesystems.
> Looks sane and will probably makes things faster.
This should normally not be needed. Firstly there is logic in the
write code to send off a request as soon as we have scheduled wsize
bytes worth of data. Secondly there is the 'flushd' daemon that exists
in order to time out requests, and to flush them out if the first
logic fails to do so.
That said, the __sync_one() thing is of interest to me. You'll notice
that our lack of a write_inode() means that we don't currently support
the sync() system call. Furthermore, we do O_SYNC through the slower
method of actually making our commit_write() method make a synchronous
call.
I have a patch that implements write_inode() and removes our current
O_SYNC code on
http://www.fys.uio.no/~trondmy/src/linux-2.4.4-write_inode.dif
It's been running for a month or two on my systems, but I've been wary
of sending it to Linus as it's not, strictly speaking, a bugfix.
Cheers,
Trond
next prev parent reply other threads:[~2001-05-10 12:00 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-05-08 14:00 nfs MAP_SHARED corruption fix Andrea Arcangeli
2001-05-08 15:21 ` Trond Myklebust
2001-05-08 15:38 ` Kurt Garloff
2001-05-09 7:30 ` Trond Myklebust
2001-05-09 13:25 ` Andrea Arcangeli
2001-05-09 22:02 ` Marcelo Tosatti
2001-05-10 0:08 ` Andrea Arcangeli
2001-05-09 22:38 ` Marcelo Tosatti
2001-05-10 1:16 ` Andrea Arcangeli
2001-05-10 0:00 ` Marcelo Tosatti
2001-05-10 10:11 ` Trond Myklebust [this message]
2001-05-10 10:14 ` Trond Myklebust
2001-05-09 2:48 ` Andrea Arcangeli
2001-05-09 7:00 ` Trond Myklebust
-- strict thread matches above, loose matches on Subject: below --
2001-05-09 10:55 Kurt Garloff
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=15098.26967.99796.538394@charged.uio.no \
--to=trond.myklebust@fys.uio.no \
--cc=andrea@suse.de \
--cc=garloff@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo@conectiva.com.br \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox