All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: "Holger Hoffstätte" <holger.hoffstaette@googlemail.com>
Cc: linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: 3.18.1: broken directory with one file too many
Date: Thu, 18 Dec 2014 09:48:56 -0500	[thread overview]
Message-ID: <20141218144856.GA18179@fieldses.org> (raw)
In-Reply-To: <5492C710.20104@googlemail.com>

On Thu, Dec 18, 2014 at 01:22:40PM +0100, Holger Hoffstätte wrote:
> On 12/17/14 22:22, J. Bruce Fields wrote:
> > On Tue, Dec 16, 2014 at 10:19:18PM +0000, Holger Hoffstätte wrote:
> >> (..oddly broken directory over NFS..)
> > That doesn't sound familiar.  A network trace showing the READDIR would
> > be really useful.  Since this is so reproducible, I think that should be
> > possible.  So do something like:
> > 
> > 	move the problem file into 3.14/
> > 	tcpdump -s0 -wtmp.pcap -i<relevant interface>
> > 	ls the directory on the client.
> > 	kill tcpdump
> > 	send us tmp.pcap and/or take a look at it with wireshark and see
> > 	what the READDIR response looks like.
> 
> Thanks for your reply. I forgot to mention that removing other files seems to "fix" the problem, so it does not seem to be spefically the new file itself that is the cause.
> 
> I captured the "ls 3.14 | head" sequence on both the client and the server, and put the tcpudmp files here: http://hoho.duckdns.org/linux/ - let me know if that helped.

On a quick skim, the server's READDIR responses look correct.  The entry
btrfs-20141216-fix-a-warning-of-qgroup-account-on-shared-extents.patch
is returned in frame 53 (with complete reassembled reply displayed by
wireshark in frame 63).

You could double-check for me--just run "wireshark nfs-server.pcap",
look for packets labeled "Reply ... READDIR", and expand out the READDIR
op and directory listing.  I don't see anything obviously wrong.

It's interesting that there's only one LOOKUP in the trace, for btrfs-20
(returning, not suprisingly, NFS4ERR_NOENT).  If the client failed to
parse that entry for some reason, then maybe in addition to getting the
filename wrong it also failed to get the attributes, triggering the
extra lookup/getattr.

> Meanwhile I'll try older/plain (unpatched) kernels. So far reverting the client to vanilla 3.18.1 or 3.14.27 has not helped..

I'm a little unclear: when you said "All this is on freshly baked
3.18.1", are you describing the client, or the server, or both?

--b.

  parent reply	other threads:[~2014-12-18 14:48 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-16 22:19 3.18.1: broken directory with one file too many Holger Hoffstätte
2014-12-16 22:19 ` Holger Hoffstätte
2014-12-17 21:22 ` J. Bruce Fields
2014-12-18 12:22   ` Holger Hoffstätte
2014-12-18 12:51     ` Holger Hoffstätte
2014-12-18 12:59       ` Holger Hoffstätte
2014-12-18 14:48     ` J. Bruce Fields [this message]
2014-12-18 14:58       ` Benjamin Coddington
2014-12-18 15:19         ` J. Bruce Fields
2014-12-18 15:42           ` Holger Hoffstätte
2014-12-18 16:32             ` J. Bruce Fields
2014-12-18 16:42               ` Holger Hoffstätte
2014-12-18 17:06                 ` J. Bruce Fields
2014-12-18 19:44                   ` Holger Hoffstätte
2014-12-20 18:02                     ` J. Bruce Fields
2014-12-20 18:50                       ` Holger Hoffstätte
2015-01-07  0:25                       ` Holger Hoffstätte
2015-01-07 18:21                         ` J. Bruce Fields
2015-01-07 20:06                           ` [PATCH] nfsd4: tweak rd_dircount accounting J. Bruce Fields
2014-12-18 17:18           ` 3.18.1: broken directory with one file too many J. Bruce Fields
2014-12-18 15:35       ` Holger Hoffstätte
2014-12-18 16:30         ` J. Bruce Fields

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=20141218144856.GA18179@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=holger.hoffstaette@googlemail.com \
    --cc=linux-kernel@vger.kernel.org \
    --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.