From owner-freebsd-current@FreeBSD.ORG Sat Jun 2 03:12:22 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 8B5E616A400; Sat, 2 Jun 2007 03:12:22 +0000 (UTC) (envelope-from gad@FreeBSD.org) Received: from smtp6.server.rpi.edu (smtp6.server.rpi.edu [128.113.2.226]) by mx1.freebsd.org (Postfix) with ESMTP id 50E6C13C447; Sat, 2 Jun 2007 03:12:22 +0000 (UTC) (envelope-from gad@FreeBSD.org) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp6.server.rpi.edu (8.13.1/8.13.1) with ESMTP id l523CJG3029095; Fri, 1 Jun 2007 23:12:20 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20070601211948.GB80261@turion.vk2pj.dyndns.org> References: <20070601102516.Q77697@fledge.watson.org> <20070601211948.GB80261@turion.vk2pj.dyndns.org> Date: Fri, 1 Jun 2007 23:12:18 -0400 To: Peter Jeremy From: Garance A Drosehn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-RPI-SA-Score: undef - spam scanning disabled X-CanItPRO-Stream: default X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.226 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: Sat, 02 Jun 2007 03:12:22 -0000 At 7:19 AM +1000 6/2/07, Peter Jeremy wrote: >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 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. Well, I didn't know if Robert was talking about doing just the work at the lower system levels, or just at the user-visible levels, or both. Given that I wasn't doing the work, I wanted to tread softly :-) > > 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. With distributed filesystems such as OpenAFS, a 64-bit dev_t would be very useful. With OpenAFS, a single system can reference AFS volumes from hundreds of sites, and each site can have tens of thousands of separate AFS volumes. Given the way AFS works, each AFS volume would pretty much have to be a separate st_dev device. (this has been gone over in previous discussions of stat changes...) >What other struct stat changes are up for discussion? I assume the timestamp-related ones. Either for going to a 64-bit time_t on the platforms we don't already have it (or at least reserving the room for 64-bit time_t's), or maybe increasing the resolution to sub-second. Seems to me there were some others. It might be better for us to concentrate on getting to 7.0-RELEASE for now, and then open up the discussion for what we'd want in 8.x-current once we're sure 7.x has all the major problems worked out of it. -- Garance Alistair Drosehn = drosehn@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA