Re: nfs loff_t fix not in 2.6.3?

[Randy.Dunlap]

On Sun, 22 Feb 2004 21:42:57 -0800 Mike Fedyk <mfedyk@xxxxxxxxxxxxx> wrote:

| I have this patch below to fix the 4GB file size limit with knfsd.  Is it
| still needed (alternate fix?), and what's the status of it?

It was merged after 2.6.3:
http://linux.bkbits.net:8080/linux-2.5/cset@xxxxxxxxxxx?nav=index.html|ChangeSet@-7d

Should be in any recent 2.6.3 + bk patch.

~Randy

| Thanks,
| 
| Mike
| 
| Return-path: <neilb@xxxxxxxxxxxxxxx>
| Envelope-to: mfedyk@xxxxxxxxxxxxx
| Delivery-date: Mon, 09 Feb 2004 21:55:00 -0800
| Received: from note.orchestra.cse.unsw.edu.au ([129.94.242.24] ident=root)
| 	by fileserver.matchmail.com with smtp (Exim 4.30)
| 	id 1AqQrL-0002hF-Ca
| 	for mfedyk@xxxxxxxxxxxxx; Mon, 09 Feb 2004 21:54:59 -0800
| Received: From notabene ([129.94.211.194] == dulcimer.orchestra.cse.unsw.EDU.AU)
| 	(for <akpm@xxxxxxxx>) (for <mfedyk@xxxxxxxxxxxxx>)
| 	(for <linux-kernel@xxxxxxxxxxxxxxx>) By note With Smtp ;
| 	Tue, 10 Feb 2004 16:54:51 +1100 
| Received: from neilb by notabene with local (Exim 3.36 #1 (Debian))
| 	id 1AqQqR-0002IH-00; Tue, 10 Feb 2004 16:54:03 +1100
| From: Neil Brown <neilb@xxxxxxxxxxxxxxx>
| To: Andrew Morton <akpm@xxxxxxxx>
| Date: Tue, 10 Feb 2004 16:53:56 +1100
| MIME-Version: 1.0
| Content-Type: text/plain; charset=us-ascii
| Content-Transfer-Encoding: 7bit
| Message-ID: <16424.29172.314124.933554@xxxxxxxxxxxxxxxxxxxxxxxx>
| Cc: Mike Fedyk <mfedyk@xxxxxxxxxxxxx>,
|     linux-kernel@xxxxxxxxxxxxxxx
| Subject: Re: 4.1GB limit with nfs3, 2.6 & knfsd?
| In-Reply-To: message from Andrew Morton on Monday February 9
| References: <20040210043926.GG18674@xxxxxxxxxxxxxxxxxxxxxxxxx>
| 	<20040209215020.60cf2f93.akpm@xxxxxxxx>
| X-Mailer: VM 7.18 under Emacs 21.3.1
| X-face: [Gw_3E*Gng}4rRrKRYotwlE?.2|**#s9D<ml'fY1Vw+@XfR[fRCsUoP?K6bt3YD\ui5Fh?f
| 	LONpR';(ql)VM_TQ/<l_^D3~B:z$\YC7gUCuC=sYm/80G=$tt"98mr8(l))QzVKCk$6~gldn~*FK9x
| 	8`;pM{3S8679sP+MbP,72<3_PIH-$I&iaiIb|hV1d%cYg))BmI)AZ
| X-Spam-DCC: : 
| X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on 
| 	fileserver.matchmail.com
| X-Spam-Level: 
| X-Spam-Status: No, hits=-4.9 required=6.0 tests=BAYES_00 autolearn=ham 
| 	version=2.61
| Content-Length: 4358
| 
| On Monday February 9, akpm@xxxxxxxx wrote:
| > Mike Fedyk <mfedyk@xxxxxxxxxxxxx> 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@xxxxxxxxxx>
| 
| 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 *);
| 
| -
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/