All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stan Hu <stanhu@gmail.com>
To: linux-nfs@vger.kernel.org
Subject: Stale data after file is renamed while another process has an open file handle
Date: Mon, 17 Sep 2018 13:57:17 -0700	[thread overview]
Message-ID: <CAMBWrQ=xMMsHxSP8uw_H3KkMK9tUQWLYjt8yAQmFm8NDLD7pyQ@mail.gmail.com> (raw)

On both kernels in Ubuntu 16.04 (4.4.0-130) and CentOS 7.3
(3.10.0-862.11.6.el7.x86_64) with NFS 4.1, I'm seeing an issue where
stale data is shown if a file remains open on one machine, and the
file is overwritten via a rename() on another. Here's my test:

1. On node A, create two different files on a shared NFS mount:
"test1.txt" and "test2.txt".
2. On node B, continuously show the contents of the first file: "while
true; do cat test1.txt; done"
3. On node B, run a process that keeps "test1.txt" open. For example,
with Python, run:
     f = open('/nfs-mount/test.txt', 'r')
4. Rename test2.txt via "mv -f test2.txt test1.txt"

On node B, I see the contents of the original test1.txt indefinitely,
even after I disabled attribute caching and the lookup cache. I can
make the while loop in step 2 show the new content if I perform one of
these actions:

1. Run "ls /nfs-mount"
2. Close the open file in step 3

I suspect the first causes the readdir cache revalidation to happen.

Is this intended behavior, or is there a better way to achieve
consistency here without performing one of these actions?

Note that with an Isilon NFS server, instead of seeing stale content,
I see "Stale file handle" errors indefinitely unless I perform one of
the corrective steps.

             reply	other threads:[~2018-09-18  2:26 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-17 20:57 Stan Hu [this message]
2018-09-17 21:15 ` Stale data after file is renamed while another process has an open file handle J. Bruce Fields
2018-09-17 21:37   ` Stan Hu
2018-09-17 22:01     ` J. Bruce Fields
     [not found]       ` <CAMBWrQmRtPHOFbiMsz2YAn-yQXCYjRBqq0zLJUB7snPg2MQ+tA@mail.gmail.com>
2018-09-17 22:48         ` Stan Hu
2018-09-18 17:42           ` Stan Hu
2018-09-18 18:33             ` J. Bruce Fields
2018-09-18 19:06               ` Chris Siebenmann
2018-09-18 19:27                 ` J. Bruce Fields
2018-09-18 18:19           ` J. Bruce Fields
2018-09-19 17:39             ` Stan Hu
2018-09-19 20:02               ` Bruce Fields
2018-09-20  0:18                 ` Bruce Fields
2018-09-20 18:23                 ` Stan Hu
2018-09-20 18:39                   ` Bruce Fields
2018-09-24 20:34                     ` Stan Hu
2018-09-25 18:56                       ` Stan Hu
2018-09-25 20:34                         ` Bruce Fields
2018-09-25 20:40                           ` Stan Hu

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='CAMBWrQ=xMMsHxSP8uw_H3KkMK9tUQWLYjt8yAQmFm8NDLD7pyQ@mail.gmail.com' \
    --to=stanhu@gmail.com \
    --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.