* 4.1GB limit with nfs3, 2.6 & knfsd? @ 2004-02-10 4:39 Mike Fedyk 2004-02-10 5:50 ` Andrew Morton 0 siblings, 1 reply; 6+ messages in thread From: Mike Fedyk @ 2004-02-10 4:39 UTC (permalink / raw) To: linux-kernel Hi, I was trying to tar and bzip2 some directories over the weekend and I think I may have found a bug. The operation would consistantly fail when the bzip2ed tar file hit 4.1GB when directed at a 2.6.1-bk2-nfs-stale-file-handles knfsd server from another computer running the same kernel. If I try the operation against a local filesystem, or a 2.4.24 knfsd server on the network there are no failures and the file is at 18GB and growing on the local filesystem (not enough space on the 2.4 server...). This is all from the same nfs client computer. I plan on doing some more tests with dd and cat against the server after the files have finished compressing. Anyone have any ideas? I know this could be userspace, but why does it work against a 2.4 knfsd and on the local filesystem? ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: 4.1GB limit with nfs3, 2.6 & knfsd? 2004-02-10 4:39 4.1GB limit with nfs3, 2.6 & knfsd? Mike Fedyk @ 2004-02-10 5:50 ` Andrew Morton 2004-02-10 5:53 ` Neil Brown 0 siblings, 1 reply; 6+ messages in thread From: Andrew Morton @ 2004-02-10 5:50 UTC (permalink / raw) To: Mike Fedyk; +Cc: linux-kernel, Neil Brown Mike Fedyk <mfedyk@matchmail.com> wrote: > > Hi, > > I was trying to tar and bzip2 some directories over the weekend and I think > I may have found a bug. > > The operation would consistantly fail when the bzip2ed tar file hit 4.1GB > when directed at a 2.6.1-bk2-nfs-stale-file-handles knfsd server from > another computer running the same kernel. > > If I try the operation against a local filesystem, or a 2.4.24 knfsd server > on the network there are no failures and the file is at 18GB and growing on > the local filesystem (not enough space on the 2.4 server...). > > This is all from the same nfs client computer. > > I plan on doing some more tests with dd and cat against the server after the > files have finished compressing. > > Anyone have any ideas? I know this could be userspace, but why does it work > against a 2.4 knfsd and on the local filesystem? Yes, something funny does seem to be happening. I have a simple NFS mount of an ext2 filesystem via localhost and a 6GB `dd' fails after 4G: vmm:/mnt/localhost> strace dd if=/dev/zero of=foo bs=1M count=6000 ... write(1, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) = 1048576 read(0, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) = 1048576 write(1, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) = 1048576 read(0, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) = 1048576 write(1, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) = -1 EINVAL (Invalid argument) vmm:/mnt/localhost> ls -l foo -rw-r--r-- 1 akpm akpm 4296015872 Feb 9 21:36 foo But after that, one can continue to grow the file: vmm:/mnt/localhost> cat /dev/zero >> foo ^C vmm:/mnt/localhost> ls -l foo -rw-r--r-- 1 akpm akpm 4573638656 Feb 9 21:48 foo Maybe Neil can shed some light? ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: 4.1GB limit with nfs3, 2.6 & knfsd? 2004-02-10 5:50 ` Andrew Morton @ 2004-02-10 5:53 ` Neil Brown 2004-02-10 6:08 ` Mike Fedyk 2004-02-10 6:38 ` Andrew Morton 0 siblings, 2 replies; 6+ messages in thread From: Neil Brown @ 2004-02-10 5:53 UTC (permalink / raw) To: Andrew Morton; +Cc: Mike Fedyk, linux-kernel On Monday February 9, akpm@osdl.org wrote: > Mike Fedyk <mfedyk@matchmail.com> wrote: > > > > Hi, > > > > I was trying to tar and bzip2 some directories over the weekend and I think > > I may have found a bug. > > > > The operation would consistantly fail when the bzip2ed tar file hit 4.1GB > > when directed at a 2.6.1-bk2-nfs-stale-file-handles knfsd server from > > another computer running the same kernel. > > > > If I try the operation against a local filesystem, or a 2.4.24 knfsd server > > on the network there are no failures and the file is at 18GB and growing on > > the local filesystem (not enough space on the 2.4 server...). > > > > This is all from the same nfs client computer. > > > > I plan on doing some more tests with dd and cat against the server after the > > files have finished compressing. > > > > Anyone have any ideas? I know this could be userspace, but why does it work > > against a 2.4 knfsd and on the local filesystem? > > Yes, something funny does seem to be happening. > > I have a simple NFS mount of an ext2 filesystem via localhost and a 6GB > `dd' fails after 4G: > > vmm:/mnt/localhost> strace dd if=/dev/zero of=foo bs=1M count=6000 > ... > write(1, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) = 1048576 > read(0, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) = 1048576 > write(1, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) = 1048576 > read(0, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) = 1048576 > write(1, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) = -1 EINVAL (Invalid argument) > This is probably fixed by the following patch that is sitting in my queue. While 2.4 technically needs the same patch, it isn't affected because it completely ignores the "offset", rather than almost-completely ignoring it. NeilBrown ------------------------------------------------------- off_t in nfsd_commit needs to be loff_t From: Miquel van Smoorenburg <miquels@cistron.nl> While I was stress-testing NFS/XFS on 2.6.1/2.6.2-rc, I found that sometimes my "dd" would exit with: # dd if=/dev/zero bs=4096 > /mnt/file dd: writing `standard output': Invalid argument 1100753+0 records in 1100752+0 records out After adding some debug printk's to the server and client code and some tcpdump-ing, I found that the NFSERR_INVAL was returned by nfsd_commit on the server. Turns out that the "offset" argument is off_t instead of loff_t. It isn't used at all (unfortunately), but it _is_ checked for sanity, so that's where the error came from. ----------- Diffstat output ------------ ./fs/nfsd/nfs3proc.c | 4 ++-- ./fs/nfsd/vfs.c | 2 +- ./include/linux/nfsd/nfsd.h | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff ./fs/nfsd/nfs3proc.c~current~ ./fs/nfsd/nfs3proc.c --- ./fs/nfsd/nfs3proc.c~current~ 2004-02-06 13:38:28.000000000 +1100 +++ ./fs/nfsd/nfs3proc.c 2004-02-06 13:38:28.000000000 +1100 @@ -595,10 +595,10 @@ nfsd3_proc_commit(struct svc_rqst * rqst { int nfserr; - dprintk("nfsd: COMMIT(3) %s %d@%ld\n", + dprintk("nfsd: COMMIT(3) %s %u@%Lu\n", SVCFH_fmt(&argp->fh), argp->count, - (unsigned long) argp->offset); + (unsigned long long) argp->offset); if (argp->offset > NFS_OFFSET_MAX) RETURN_STATUS(nfserr_inval); diff ./fs/nfsd/vfs.c~current~ ./fs/nfsd/vfs.c --- ./fs/nfsd/vfs.c~current~ 2004-02-06 13:38:21.000000000 +1100 +++ ./fs/nfsd/vfs.c 2004-02-06 13:38:28.000000000 +1100 @@ -823,7 +823,7 @@ out: */ int nfsd_commit(struct svc_rqst *rqstp, struct svc_fh *fhp, - off_t offset, unsigned long count) + loff_t offset, unsigned long count) { struct file file; int err; diff ./include/linux/nfsd/nfsd.h~current~ ./include/linux/nfsd/nfsd.h --- ./include/linux/nfsd/nfsd.h~current~ 2004-02-06 13:38:24.000000000 +1100 +++ ./include/linux/nfsd/nfsd.h 2004-02-06 13:38:28.000000000 +1100 @@ -86,7 +86,7 @@ int nfsd_create_v3(struct svc_rqst *, s struct svc_fh *res, int createmode, u32 *verifier, int *truncp); int nfsd_commit(struct svc_rqst *, struct svc_fh *, - off_t, unsigned long); + loff_t, unsigned long); #endif /* CONFIG_NFSD_V3 */ int nfsd_open(struct svc_rqst *, struct svc_fh *, int, int, struct file *); ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: 4.1GB limit with nfs3, 2.6 & knfsd? 2004-02-10 5:53 ` Neil Brown @ 2004-02-10 6:08 ` Mike Fedyk 2004-02-10 6:15 ` Neil Brown 2004-02-10 6:38 ` Andrew Morton 1 sibling, 1 reply; 6+ messages in thread From: Mike Fedyk @ 2004-02-10 6:08 UTC (permalink / raw) To: Neil Brown; +Cc: Andrew Morton, linux-kernel On Tue, Feb 10, 2004 at 04:53:56PM +1100, Neil Brown wrote: > On Monday February 9, akpm@osdl.org wrote: > > Mike Fedyk <mfedyk@matchmail.com> wrote: > > > > > > Hi, > > > > > > I was trying to tar and bzip2 some directories over the weekend and I think > > > I may have found a bug. > > > > > > The operation would consistantly fail when the bzip2ed tar file hit 4.1GB > > > when directed at a 2.6.1-bk2-nfs-stale-file-handles knfsd server from > > > another computer running the same kernel. > > > > > > If I try the operation against a local filesystem, or a 2.4.24 knfsd server > > > on the network there are no failures and the file is at 18GB and growing on > > > the local filesystem (not enough space on the 2.4 server...). > > > > > > This is all from the same nfs client computer. > > > > > > I plan on doing some more tests with dd and cat against the server after the > > > files have finished compressing. > > > > > > Anyone have any ideas? I know this could be userspace, but why does it work > > > against a 2.4 knfsd and on the local filesystem? > > > > Yes, something funny does seem to be happening. > > > > I have a simple NFS mount of an ext2 filesystem via localhost and a 6GB > > `dd' fails after 4G: > > > > vmm:/mnt/localhost> strace dd if=/dev/zero of=foo bs=1M count=6000 > > ... > > write(1, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) = 1048576 > > read(0, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) = 1048576 > > write(1, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) = 1048576 > > read(0, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) = 1048576 > > write(1, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) = -1 EINVAL (Invalid argument) > > > > This is probably fixed by the following patch that is sitting in my > queue. > While 2.4 technically needs the same patch, it isn't affected because > it completely ignores the "offset", rather than almost-completely > ignoring it. > > NeilBrown Would this patch work with 2.6.1-bk2-nfs-stale-file-handles, or does it depend on any other patches? ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: 4.1GB limit with nfs3, 2.6 & knfsd? 2004-02-10 6:08 ` Mike Fedyk @ 2004-02-10 6:15 ` Neil Brown 0 siblings, 0 replies; 6+ messages in thread From: Neil Brown @ 2004-02-10 6:15 UTC (permalink / raw) To: Mike Fedyk; +Cc: Andrew Morton, linux-kernel On Monday February 9, mfedyk@matchmail.com wrote: > > > > This is probably fixed by the following patch that is sitting in my > > queue. .... > > Would this patch work with 2.6.1-bk2-nfs-stale-file-handles, or does it > depend on any other patches? It doesn't depend on, or conflict with, any other patches (to my knowledge). NeilBrown ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: 4.1GB limit with nfs3, 2.6 & knfsd? 2004-02-10 5:53 ` Neil Brown 2004-02-10 6:08 ` Mike Fedyk @ 2004-02-10 6:38 ` Andrew Morton 1 sibling, 0 replies; 6+ messages in thread From: Andrew Morton @ 2004-02-10 6:38 UTC (permalink / raw) To: Neil Brown; +Cc: mfedyk, linux-kernel Neil Brown <neilb@cse.unsw.edu.au> wrote: > > > write(1, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) = -1 EINVAL (Invalid argument) > > > > This is probably fixed by the following patch that is sitting in my > queue. Indeed it is, thanks. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-02-10 6:36 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2004-02-10 4:39 4.1GB limit with nfs3, 2.6 & knfsd? Mike Fedyk 2004-02-10 5:50 ` Andrew Morton 2004-02-10 5:53 ` Neil Brown 2004-02-10 6:08 ` Mike Fedyk 2004-02-10 6:15 ` Neil Brown 2004-02-10 6:38 ` Andrew Morton
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox