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 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.