From owner-freebsd-fs@FreeBSD.ORG Mon Jun 6 13:47:50 2005 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 25A1216A41C; Mon, 6 Jun 2005 13:47:50 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 93C8D43D53; Mon, 6 Jun 2005 13:47:46 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [10.0.2.2] ([12.174.84.3]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j56Dreaf052274; Mon, 6 Jun 2005 07:53:47 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42A453B5.3020006@samsco.org> Date: Mon, 06 Jun 2005 07:46:29 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Garance A Drosihn References: <82ACAD58-B179-44E2-852F-60F25C0BBBC1@FreeBSD.org> <20050606033145.GA80739@www.portaone.com> <42A3D6CF.2000504@samsco.org> <0A6C1F19-A734-4EC8-BE97-2D000D189968@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=3.8 tests=none autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: Suleiman Souhlal , current@freebsd.org, fs@freebsd.org Subject: Re: [PATCH] IFS: Inode FileSystem 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, 06 Jun 2005 13:47:50 -0000 Garance A Drosihn wrote: > At 1:05 AM -0400 6/6/05, Suleiman Souhlal wrote: > >> >> On Jun 6, 2005, at 12:53 AM, Scott Long wrote: >> >>> It's a huge win for CPU overhead in the filesystem, especially >>> when we start talking about increasing the size of m_links >>> field and possibly going 64-bit inode numbers. >> >> >> Talking about going to 64-bit inode numbers, how would we deal >> with the change in stat(2)? > > > By making some sort of incompatible change to stat(2). This has > been discussed from time-to-time. It's another change that I > would have liked to have seen (at least for the stat routines) > in 6.0, but right now I suspect it will not happen until 7.0. > We can't go making incremental incompatibilities to the filesystem without a good deal of planning. This is the type of thing that would go into a 'UFS3'. I have some long-term plans here, but I need to get the initial proof-of-concept journalling working before I start to seriously consider what else would be in UFS3. Scott