From owner-freebsd-fs@FreeBSD.ORG Mon Feb 1 20:36:36 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EECF106566C; Mon, 1 Feb 2010 20:36:36 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (chez.mckusick.com [64.81.247.49]) by mx1.freebsd.org (Postfix) with ESMTP id 20F3C8FC08; Mon, 1 Feb 2010 20:36:35 +0000 (UTC) Received: from chez.mckusick.com (localhost [127.0.0.1]) by chez.mckusick.com (8.14.3/8.14.3) with ESMTP id o11KaXLE038927; Mon, 1 Feb 2010 12:36:33 -0800 (PST) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201002012036.o11KaXLE038927@chez.mckusick.com> To: Jaakko Heinonen In-reply-to: <20100201102918.GA2505@a91-153-117-195.elisa-laajakaista.fi> Date: Mon, 01 Feb 2010 12:36:33 -0800 From: Kirk McKusick Cc: freebsd-fs@freebsd.org Subject: Re: Inode number treated as signed int in ffs_nodealloccg X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 20:36:36 -0000 > Date: Mon, 1 Feb 2010 12:29:18 +0200 > From: Jaakko Heinonen > To: Scott Burns > Cc: freebsd-fs@freebsd.org > Subject: Re: Inode number treated as signed int in ffs_nodealloccg > > On 2010-01-31, Scott Burns wrote: > > I imagine that this hasn't been noticed up to now since most people are > > not exceeding the range of a signed int, even with multi-TB filesystems. > > This PR may be related to this: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/133980 > http://docs.freebsd.org/cgi/mid.cgi?20090508120355.S1497 > > -- > Jaakko Thanks for that pointer. I will look into getting Scott Burns fix into the tree which should correct it. I will also ensure that newfs scales back the number of inodes per cylinder group to keep the total number under 2^32. The long-term solution is to go to 64-bit inode numbers, but that will have to wait for a major filesystem revision. Kirk McKusick