From owner-freebsd-fs@FreeBSD.ORG Tue Oct 7 22:16:26 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7F76A945; Tue, 7 Oct 2014 22:16:26 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 369138F5; Tue, 7 Oct 2014 22:16:25 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq8EAMJkNFSDaFve/2dsb2JhbABfDoQrBIMA0HECgScBe4QDAQEBAwEjVhsYAgINGQJZBhOINgitNpUTAReBLI5PFTQHgneBVAWRTo0hkFyDf4MjXCEvgQYBHwQegQIBAQE X-IronPort-AV: E=Sophos;i="5.04,673,1406606400"; d="scan'208";a="158864915" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 07 Oct 2014 18:16:24 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id EA971B4060; Tue, 7 Oct 2014 18:16:24 -0400 (EDT) Date: Tue, 7 Oct 2014 18:16:24 -0400 (EDT) From: Rick Macklem To: Garrett Wollman Message-ID: <654363730.60050348.1412720184948.JavaMail.root@uoguelph.ca> In-Reply-To: <21556.24590.269326.188103@khavrinen.csail.mit.edu> 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.203] 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 22:16:26 -0000 Garrett Wollman wrote: > < said: > > >> 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? > > Nope. (And I want to emphasize that Ubuntu clients don't exhibit the > problem, so whatever it is, it doesn't appear to be related to the > backing filesystem on the server.) > Well, not many things in FreeBSD break when the i-node#s get truncated. fts(3) will complain about a possible loop in the directory structure, but I'm not aware of much else. I have no idea what might break in the Ubuntu client for this case. All I'm saying is that "it works for Ubuntu" suggests that the bug is in the FreeBSD client (or FreeBSD port of bonnie++), but doesn't guarantee that there isn't a server side problem being exposed by the FreeBSD client. rick ps: I would like to hear what happens when you test against a UFS volume. > > 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.) > > You really need to get some server-class hardware. Perhaps the > Foundation can help? > > I'm currently using the following command, which seems to reproduce > the problem reliably on my client and server: > > bonnie++ -s 0 -n 144:0:0:1:16384 -u 4294967294 -D > > This minimizes the amount of temporary storage required. > > -GAWollman >