From owner-freebsd-fs@FreeBSD.ORG Sun Jul 4 00:41:06 2004 Return-Path: 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 9ABAA16A4CE; Sun, 4 Jul 2004 00:41:06 +0000 (GMT) Received: from robbins.dropbear.id.au (043.b.010.mel.iprimus.net.au [210.50.201.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id F3A9343D3F; Sun, 4 Jul 2004 00:41:05 +0000 (GMT) (envelope-from tim@robbins.dropbear.id.au) Received: by robbins.dropbear.id.au (Postfix, from userid 1000) id C32E7421F; Sun, 4 Jul 2004 10:44:44 +1000 (EST) Date: Sun, 4 Jul 2004 10:44:44 +1000 From: Tim Robbins To: Alfred Perlstein Message-ID: <20040704004444.GA52008@cat.robbins.dropbear.id.au> References: <200407031322.i63DMdqC084182@repoman.freebsd.org> <20040703230127.GG95729@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040703230127.GG95729@elvis.mu.org> User-Agent: Mutt/1.4.1i cc: freebsd-fs@freebsd.org Subject: Re: cvs commit: src/sys/conf NOTES files options src/sys/fs/msdosfs msdosfs_fileno.c msdosfs_vfsops.c msdosfs_vnops.c msdosfsmount.h src/sys/modules/msdosfs Makefile X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jul 2004 00:41:06 -0000 On Sat, Jul 03, 2004 at 04:01:27PM -0700, Alfred Perlstein wrote: > What are the implications of expanding the VFS API to take 64bit > inodes? Widening ino_t to 64 bits would change the layout/size of struct stat, so we'd have to add a new stat() syscall (as well as fstat(), lstat()) and add compatibility code for binaries that expect the old layout. We'd also have to sweep through VFS to find the instances where i-numbers are being stored in wrong types, e.g. struct vattr's va_fileid member uses 'long' instead of 'ino_t' for some reason. I think it's something that would be best left until 6-CURRENT. Tim From owner-freebsd-fs@FreeBSD.ORG Sun Jul 4 02:09:16 2004 Return-Path: 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 4EB4316A4CE; Sun, 4 Jul 2004 02:09:16 +0000 (GMT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34E3143D31; Sun, 4 Jul 2004 02:09:16 +0000 (GMT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id EDDDC5C843; Sat, 3 Jul 2004 19:09:15 -0700 (PDT) Date: Sat, 3 Jul 2004 19:09:15 -0700 From: Alfred Perlstein To: Tim Robbins Message-ID: <20040704020915.GI95729@elvis.mu.org> References: <200407031322.i63DMdqC084182@repoman.freebsd.org> <20040703230127.GG95729@elvis.mu.org> <20040704004444.GA52008@cat.robbins.dropbear.id.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040704004444.GA52008@cat.robbins.dropbear.id.au> User-Agent: Mutt/1.4.2.1i cc: freebsd-fs@freebsd.org Subject: Re: cvs commit: src/sys/conf NOTES files options src/sys/fs/msdosfs msdosfs_fileno.c msdosfs_vfsops.c msdosfs_vnops.c msdosfsmount.h src/sys/modules/msdosfs Makefile X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jul 2004 02:09:16 -0000 * Tim Robbins [040703 17:41] wrote: > On Sat, Jul 03, 2004 at 04:01:27PM -0700, Alfred Perlstein wrote: > > What are the implications of expanding the VFS API to take 64bit > > inodes? > > Widening ino_t to 64 bits would change the layout/size of struct stat, so > we'd have to add a new stat() syscall (as well as fstat(), lstat()) and add > compatibility code for binaries that expect the old layout. We'd also have > to sweep through VFS to find the instances where i-numbers are being stored > in wrong types, e.g. struct vattr's va_fileid member uses 'long' instead > of 'ino_t' for some reason. I think it's something that would be best > left until 6-CURRENT. Bah, we can do it. :) -- - Alfred Perlstein - Research Engineering Development Inc. - email: bright@mu.org cell: 408-480-4684 From owner-freebsd-fs@FreeBSD.ORG Sun Jul 4 03:55:49 2004 Return-Path: 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 845B416A4CF; Sun, 4 Jul 2004 03:55:49 +0000 (GMT) Received: from smtp4.server.rpi.edu (smtp4.server.rpi.edu [128.113.2.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 311CF43D46; Sun, 4 Jul 2004 03:55:49 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp4.server.rpi.edu (8.12.8/8.12.8) with ESMTP id i643tlJc009754; Sat, 3 Jul 2004 23:55:48 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20040704020915.GI95729@elvis.mu.org> References: <200407031322.i63DMdqC084182@repoman.freebsd.org> <20040703230127.GG95729@elvis.mu.org> <20040704004444.GA52008@cat.robbins.dropbear.id.au> <20040704020915.GI95729@elvis.mu.org> Date: Sat, 3 Jul 2004 23:55:47 -0400 To: Alfred Perlstein , Tim Robbins From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) cc: freebsd-fs@freebsd.org Subject: Re: cvs commit: src/sys/conf NOTES files ... X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jul 2004 03:55:49 -0000 At 7:09 PM -0700 7/3/04, Alfred Perlstein wrote: >* Tim Robbins [040703 17:41] wrote: > > On Sat, Jul 03, 2004, Alfred Perlstein wrote: > > > What are the implications of expanding the VFS API to take > > > 64bit inodes? > > > > Widening ino_t to 64 bits would change the layout/size of struct > > stat, so we'd have to add a new stat() syscall (as well as fstat(), > > lstat()) and add compatibility code for binaries that expect the > > old layout. We'd also have to [...] > > I think it's something that would be best left until 6-CURRENT. > >Bah, we can do it. :) The implications are that it certainly ain't going to happen as part of 5.x-stable. It did come up at the DevSummit (at Usenix) as one of the projects we expect to tackle for the 6.0-branch. The people at the DevSummit were also pretty adamant that we must not take as long to get to a production-quality 6.x-stable as it has taken to get to 5.x-stable. I'll also note that I am hoping to see a 64-bit dev_t happen at the same time, for the benefit of filesystems like OpenAFS. ...but I am sure all this will all be written up in a more useful form and with much more detail after everyone gets back from Usenix. I was only there for Tuesday and Wednesday, while most developers were there for the whole Usenix conference. I suspect that discussions continued after the "official" DevSummit was over. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-fs@FreeBSD.ORG Tue Jul 6 16:11:17 2004 Return-Path: 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 103E216A4CE; Tue, 6 Jul 2004 16:11:17 +0000 (GMT) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1AB243D5E; Tue, 6 Jul 2004 16:11:16 +0000 (GMT) (envelope-from mday@apple.com) Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204])i66GBGlq005796; Tue, 6 Jul 2004 09:11:16 -0700 (PDT) Received: from relay1.apple.com (relay1.apple.com) by mailgate2.apple.com ; Tue, 6 Jul 2004 09:11:16 -0700 Received: from [17.112.105.102] ([17.112.105.102]) by relay1.apple.com (8.12.11/8.12.11) with ESMTP id i66GBEhc023517; Tue, 6 Jul 2004 09:11:14 -0700 (PDT) In-Reply-To: <20040703230127.GG95729@elvis.mu.org> References: <200407031322.i63DMdqC084182@repoman.freebsd.org> <20040703230127.GG95729@elvis.mu.org> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1DC8D54A-CF67-11D8-BF9F-000A95D99E06@apple.com> Content-Transfer-Encoding: 7bit From: Mark Day Date: Tue, 6 Jul 2004 09:11:19 -0700 To: "Tim J. Robbins" X-Mailer: Apple Mail (2.618) cc: Alfred Perlstein cc: fs@freebsd.org Subject: Re: cvs commit: src/sys/conf NOTES files options src/sys/fs/msdosfs msdosfs_fileno.c msdosfs_vfsops.c msdosfs_vnops.c msdosfsmount.h src/sys/modules/msdosfs Makefile X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2004 16:11:17 -0000 On Jul 3, 2004, at 4:01 PM, Alfred Perlstein wrote: >> By popular request, add a workaround that allows large (>128GB or >> so) >> FAT32 filesystems to be mounted, subject to some fairly serious >> limitations. >> >> This works by extending the internal pseudo-inode-numbers generated >> from >> the file's starting cluster number to 64-bits, then creating a table >> mapping these into arbitrary 32-bit inode numbers, which can fit in >> struct dirent's d_fileno and struct vattr's va_fileid fields. The >> mappings >> do not persist across unmounts or reboots, so it's not possible to >> export >> these filesystems through NFS. The mapping table may grow to be >> rather >> large, and may grow large enough to exhaust kernel memory on >> filesystems >> with millions of files. I haven't looked at the code, but I assume it is still using the cluster and offset of the directory entry (divided by 32, the size of a directory entry) as the inode number. You're just using 64 bits to hold that now, right? Mac OS X/Darwin addressed the >128GB problem by using the starting cluster number as the inode number. It has the advantage of not needing per-file memory. It also means that inode numbers change less (in the previous scheme, a move or rename changed the inode number because the directory entry moved). On the down side, empty files share a single inode number (Mac OS X uses an arbitrary value larger than any valid cluster number). Also, you can't look up a file by its inode number since you can't easily get back to the directory entry containing the dates and other metadata. -Mark