From owner-freebsd-fs@FreeBSD.ORG Tue Oct 7 21:06:06 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A9A4340D; Tue, 7 Oct 2014 21:06:06 +0000 (UTC) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 5EB93EFB; Tue, 7 Oct 2014 21:06:05 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUEAIVVNFSDaFve/2dsb2JhbABfDoNTWASDAMkaCoZ5VAKBJwF7hAMBAQEDAQEBASAEJyALBRYYAgINGQIpAQkmBggHBAEcBIgVCA2tN5UFAReBLI43EAEBGzQHgneBVAWWNIJBgUmEMTyQIIN/gyNcIS8HgQAIFyKBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,673,1406606400"; d="scan'208";a="160020817" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 07 Oct 2014 17:06:02 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id B8E39B4097; Tue, 7 Oct 2014 17:06:02 -0400 (EDT) Date: Tue, 7 Oct 2014 17:06:02 -0400 (EDT) From: Rick Macklem To: Garrett Wollman Message-ID: <603326314.59995969.1412715962746.JavaMail.root@uoguelph.ca> In-Reply-To: <1109402573.59384867.1412683413852.JavaMail.root@uoguelph.ca> Subject: Re: 9.3 NFS client bug? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.209] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 21:06:06 -0000 I wrote: > Garrett Wollman wrote: > > < > said: > > > > > 2 - Try an "oldnfs" mount and see if the old client exhibits the > > > same behaviour. > > > > Same behavior both old and new. I'm doing binary search now to try > > to > > minimize the size of the workload that exhibits the issue. > > > > -GAWollman > > > By ay chance is your ZFS server allocating a ZFS inode (whatever they > call it) with a fileno/inode# that doesn't fit in 32 bits? > (There is a diagnostic printf w.r.t. this for NFSv4, but not NFSv3, > so you might try an NFSv4 mount. The printf starts with "NFSv4 > fileid > 32..".) > Oops, I've realized that this diagnostic won't help if the server is a FreeBSD one, since the FreeBSD server just sets the high order 32bits to 0s and not what the file system returns. (va_filerev is a "long", so it is only 64bits on some arches, yikes.) You could try what jhb@ suggested (try a UFS file system) or just use a different ZFS volume that isn't very full, if you think the 32bit restriction could have been exceeded. Btw, I tried your bonnie++ command on my test machines, but they failed part way through because they couldn't allocate boundary tags. (At least now I can reproduce that easily, although it is the M_NOWAIT case where the thread just loops in the kernel.) rick > Since d_fileno in "struct dirent" is 32bits, NFS just truncates the > 64bit fileid to 32bits (or fills the high order 32bits with 0s for > the server). > ZFS is known to generate fileids with non-zero high order > 32bits->busted. > (And not at all easy to fix. I actually have a somewhat hackish idea > for > a way to make 64bit d_fileno values work without busting backwards > compatibility. > I think I'll post that to freebsd-fs@ and see what others think?) > > rick > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" >