public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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