From: "Doug Nazar" <nazard@dragoninc.ca>
To: "'J. Bruce Fields'" <bfields@fieldses.org>
Cc: "'David Woodhouse'" <David.Woodhouse@intel.com>,
"'Al Viro'" <viro@zeniv.linux.org.uk>,
<linux-kernel@vger.kernel.org>
Subject: RE: 2.6.28-rc3 truncates nfsd results
Date: Wed, 5 Nov 2008 06:16:28 -0500 [thread overview]
Message-ID: <004a01c93f37$f2a09090$d7e1b1b0$@ca> (raw)
In-Reply-To: <20081104223000.GG10974@fieldses.org>
> From: J. Bruce Fields [mailto:bfields@fieldses.org]
> On Tue, Nov 04, 2008 at 01:27:23PM -0500, Doug Nazar wrote:
> > Commit 8d7c4203 "nfsd: fix failure to set eof in readdir in some situations"
> > breaks the nfsd server. Bisected it back to this commit and reverting it
> > fixes the problem.
> >
> > However, it only happens on certain machines even with the same kernel &
> > filesystem (ext3). I've two groups of similar computers, each group running
> > identical kernels. The ones listing only ~250 files are of course in error.
> > Eldritch is running 2.6.28-rc3 with that commit reverted. With 2.8.28-rc3 it
> > showed the incorrect number.
>
> Well, that's strange; it must be staring me in the face, but I don't see
> the problem (and can't reproduce it). Can you watch for the readdir
> with wireshark and see if it's returning an error on the readdir? Or is
> it just returning succesfully with eof set after the first ~250
> entries?
Ok, think I've figured it out.
The computers showing the issue are not using dir_index. This causes ext3 to read a block at a time, which then means we can end up
with buf.full==0 but not finished reading the directory. Before 8d7c4203, we'd always get called again because we never set
nfserr_eof which papered over it.
I think the correct solution is to move nfserr_eof into the loop and remove the buf.full check so that we loop until buf.used==0.
The following seems to do the right thing and reduces the network traffic since we now ensure each buffer is full.
Tested on an empty directory & large directory, eof is properly sent and no short buffers.
diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
index 848a03e..4433c8f 100644
--- a/fs/nfsd/vfs.c
+++ b/fs/nfsd/vfs.c
@@ -1875,11 +1875,11 @@ static int nfsd_buffered_readdir(struct file *file, filldir_t func,
return -ENOMEM;
offset = *offsetp;
- cdp->err = nfserr_eof; /* will be cleared on successful read */
while (1) {
unsigned int reclen;
+ cdp->err = nfserr_eof; /* will be cleared on successful read */
buf.used = 0;
buf.full = 0;
@@ -1912,9 +1912,6 @@ static int nfsd_buffered_readdir(struct file *file, filldir_t func,
de = (struct buffered_dirent *)((char *)de + reclen);
}
offset = vfs_llseek(file, 0, SEEK_CUR);
- cdp->err = nfserr_eof;
- if (!buf.full)
- break;
}
done:
next prev parent reply other threads:[~2008-11-05 11:16 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-04 18:27 2.6.28-rc3 truncates nfsd results Doug Nazar
2008-11-04 18:43 ` Jeff Garzik
2008-11-04 19:03 ` David Woodhouse
2008-11-04 19:32 ` Doug Nazar
2008-11-04 20:08 ` David Woodhouse
2008-11-09 19:09 ` J. Bruce Fields
2008-11-04 19:36 ` J. Bruce Fields
2008-11-04 22:30 ` J. Bruce Fields
2008-11-05 11:16 ` Doug Nazar [this message]
2008-11-05 21:46 ` J. Bruce Fields
2008-11-05 23:07 ` J. Bruce Fields
2008-11-06 5:21 ` Doug Nazar
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='004a01c93f37$f2a09090$d7e1b1b0$@ca' \
--to=nazard@dragoninc.ca \
--cc=David.Woodhouse@intel.com \
--cc=bfields@fieldses.org \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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