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