From owner-freebsd-current@FreeBSD.ORG Fri Jun 1 21:19:50 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0BC0416A421; Fri, 1 Jun 2007 21:19:50 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-3-125.belrs4.nsw.optusnet.com.au [220.239.3.125]) by mx1.freebsd.org (Postfix) with ESMTP id 836DB13C44C; Fri, 1 Jun 2007 21:19:49 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.14.1/8.13.8) with ESMTP id l51LJmfJ080402; Sat, 2 Jun 2007 07:19:48 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.14.1/8.13.8/Submit) id l51LJmuT080401; Sat, 2 Jun 2007 07:19:48 +1000 (EST) (envelope-from peter) Date: Sat, 2 Jun 2007 07:19:48 +1000 From: Peter Jeremy To: Garance A Drosehn Message-ID: <20070601211948.GB80261@turion.vk2pj.dyndns.org> References: <20070601102516.Q77697@fledge.watson.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k1lZvvs/B4yU6o8G" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.15 (2007-04-06) Cc: Robert Watson , current@freebsd.org Subject: Re: Pending TrustedBSD stuff, etc. 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: Fri, 01 Jun 2007 21:19:50 -0000 --k1lZvvs/B4yU6o8G Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-Jun-01 11:52:07 -0400, Garance A Drosehn wrote: >> - Peter Wemm has been talking about moving us to 64-bit inode numbers > > I suspect this should wait. It would probably be better to group > together all the other changes to filesystem stat-ish data that we've > also been talking about for years, and do them all in the same major > release. Agreed. Every time we change struct stat, we need to create legacy syscalls or libc code so the fewer changes the better. > I don't know at what level you mean to move to 64-bit inode > numbers, but if (for instance) you meant a 64-bit value for st_ino, Since an inode number needs to fit into an ino_t, I would expect that ino_t and hence st_ino would both become 64-bit. > then I'd also like to see a 64-bit value for st_dev at the same time. I can see the reason for having more than 2^32 inodes in a filesystem. It's not as obvious why you would need a 64-bit dev_t. You're never going to have more than 2^32 devices attached to a system and I would suggest that it's unlikely that you would have more than 255 active drivers on one system. What other struct stat changes are up for discussion? --=20 Peter Jeremy --k1lZvvs/B4yU6o8G Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGYI10/opHv/APuIcRAr7NAKCowqYE1R1LmDLhD1tbVFGHWgt2mQCgojdA BD4Rv14/AcS/AvrrsKgs8OY= =5qbZ -----END PGP SIGNATURE----- --k1lZvvs/B4yU6o8G--