From: "J. Bruce Fields" <bfields@fieldses.org>
To: Stan Hu <stanhu@gmail.com>
Cc: linux-nfs@vger.kernel.org
Subject: Re: Stale data after file is renamed while another process has an open file handle
Date: Mon, 17 Sep 2018 18:01:07 -0400 [thread overview]
Message-ID: <20180917220107.GB21269@fieldses.org> (raw)
In-Reply-To: <CAMBWrQm2QRKNARwUf7pG_fG_ROcwXmT1PLfw5Y0ewhXzB9EqYA@mail.gmail.com>
On Mon, Sep 17, 2018 at 02:37:16PM -0700, Stan Hu wrote:
> On Mon, Sep 17, 2018 at 2:15 PM J. Bruce Fields <bfields@fieldses.org> wrote:
>
> > Sounds like a bug to me, but I'm not sure where. What filesystem are
> > you exporting? How much time do you think passes between steps 1 and 4?
> > (I *think* it's possible you could hit a bug caused by low ctime
> > granularity if you could get from step 1 to step 4 in less than a
> > millisecond.)
>
> For CentOS, I am exporting xfs. In Ubuntu, I think I was using ext4.
>
> Steps 1 through 4 are all done by hand, so I don't think we're hitting
> a millisecond issue. Just for good measure, I've done experiments
> where I waited a few minutes between steps 1 and 4.
>
> > Those kernel versions--are those the client (node A and B) versions, or
> > the server versions?
>
> The client and server kernel versions are the same across the board. I
> didn't mix and match kernels.
>
> > > 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.
> >
> > You see "stale file handle" errors from the "cat test1.txt"? That's
> > also weird.
>
> Yes, this is the problem I'm actually more concerned about, which led
> to this investigation in the first place.
It might be useful to look at the packets on the wire. So, run
something on the server like:
tcpdump -wtmp.pcap -s0 -ieth0
(replace eth0 by the relevant interface), then run the test, then kill
the tcpdump and take a look at tmp.pcap in wireshark, or send tmp.pcap
to the list (as long as there's no sensitive info in there).
What we'd be looking for:
- does the rename cause the directory's change attribute to
change?
- does the server give out a delegation, and, if so, does it
return it before allowing the rename?
- does the client do an open by filehandle or an open by name
after the rename?
--b.
next prev parent reply other threads:[~2018-09-18 3:30 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-17 20:57 Stale data after file is renamed while another process has an open file handle Stan Hu
2018-09-17 21:15 ` J. Bruce Fields
2018-09-17 21:37 ` Stan Hu
2018-09-17 22:01 ` J. Bruce Fields [this message]
[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=20180917220107.GB21269@fieldses.org \
--to=bfields@fieldses.org \
--cc=linux-nfs@vger.kernel.org \
--cc=stanhu@gmail.com \
/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;
as well as URLs for NNTP newsgroup(s).