From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Steve Dickson <SteveD@redhat.com>
Cc: nfs@lists.sourceforge.net, linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mmap corruption
Date: 05 Apr 2003 00:01:02 +0200 [thread overview]
Message-ID: <shsistt7wip.fsf@charged.uio.no> (raw)
In-Reply-To: <3E8DDB13.9020009@RedHat.com>
>>>>> " " == Steve Dickson <SteveD@redhat.com> writes:
> The Cause: Memory mapped pages were not being flushed out in a
> timely manner. When a file is about to truncated (up or down),
> nfs_writepage() is called (by filemap_fdatasync()) to flush out
> dirty pages. When this done asynchronously, nfs_writepage()
> will (indirectly) call nfs_strategy(). nfs_strategy() wants to
> send groups of pages (in this case 4 pages). Now in the error
> case, only one page was dirty so it was *not* flushed out.
> Eventually that page would be flushed (by kupdate) but it was
> too late because the file size had already change due to a
> second truncation.
That simply doesn't ring true. The nfs_wb_all() immediately after the
call to filemap_fdatasync() should ensure that *all* scheduled writes
will flushed out.
Cheers,
Trond
-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb:
Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
WARNING: multiple messages have this Message-ID (diff)
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Steve Dickson <SteveD@redhat.com>
Cc: nfs@lists.sourceforge.net, linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [NFS] [PATCH] mmap corruption
Date: 05 Apr 2003 00:01:02 +0200 [thread overview]
Message-ID: <shsistt7wip.fsf@charged.uio.no> (raw)
In-Reply-To: <3E8DDB13.9020009@RedHat.com>
>>>>> " " == Steve Dickson <SteveD@redhat.com> writes:
> The Cause: Memory mapped pages were not being flushed out in a
> timely manner. When a file is about to truncated (up or down),
> nfs_writepage() is called (by filemap_fdatasync()) to flush out
> dirty pages. When this done asynchronously, nfs_writepage()
> will (indirectly) call nfs_strategy(). nfs_strategy() wants to
> send groups of pages (in this case 4 pages). Now in the error
> case, only one page was dirty so it was *not* flushed out.
> Eventually that page would be flushed (by kupdate) but it was
> too late because the file size had already change due to a
> second truncation.
That simply doesn't ring true. The nfs_wb_all() immediately after the
call to filemap_fdatasync() should ensure that *all* scheduled writes
will flushed out.
Cheers,
Trond
next prev parent reply other threads:[~2003-04-04 22:01 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-04 19:20 [NFS] [PATCH] mmap corruption Steve Dickson
2003-04-04 22:01 ` Trond Myklebust [this message]
2003-04-04 22:01 ` Trond Myklebust
2003-04-05 16:47 ` Steve Dickson
2003-04-06 12:30 ` Trond Myklebust
2003-04-06 12:30 ` [NFS] " Trond Myklebust
2003-04-07 14:00 ` Steve Dickson
2003-04-07 14:56 ` Trond Myklebust
2003-04-07 17:39 ` Steve Dickson
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=shsistt7wip.fsf@charged.uio.no \
--to=trond.myklebust@fys.uio.no \
--cc=SteveD@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nfs@lists.sourceforge.net \
/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.