From owner-freebsd-current@FreeBSD.ORG Mon Jun 6 14:57:12 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A87A616A41C; Mon, 6 Jun 2005 14:57:12 +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 40B8343D1D; Mon, 6 Jun 2005 14:57:09 +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 j56F31j4052641; Mon, 6 Jun 2005 09:03:06 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42A463EF.5060401@samsco.org> Date: Mon, 06 Jun 2005 08:55:43 -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: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= References: <82ACAD58-B179-44E2-852F-60F25C0BBBC1@FreeBSD.org> <20050606033145.GA80739@www.portaone.com> <42A3D6CF.2000504@samsco.org> <0A6C1F19-A734-4EC8-BE97-2D000D189968@FreeBSD.org> <42A453B5.3020006@samsco.org> <86oeaj1r2x.fsf@xps.des.no> In-Reply-To: <86oeaj1r2x.fsf@xps.des.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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 , Garance A Drosihn , current@freebsd.org, fs@freebsd.org Subject: Re: [PATCH] IFS: Inode FileSystem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2005 14:57:12 -0000 Dag-Erling Smørgrav wrote: > Scott Long writes: > >>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'. > > > This is primarily an API issue, not a filesystem layout issue. We > already have at least one filesystem with 64-bit inodes (msdosfs). > > DES What do you mean it's not a layout issue? We can't make incompatible layout changes whever we feel like it, or else transportability of filesystems is completely lost and everyone who wants to boot more than just the Last And Greatest on their system winds up with unnessary pain. Anyways, I'm not looking for someone to get a wild idea that we need UFS3 right now. There are a bunch of features that would be ideal for UFS3 at a later date when we've had time to sit down and think about how to do it right. Going off and adjusting di_nlink to 32 bits and dot_ino to 64 bits and declaring that to be 'UFS3' is not a good strategy. Scott