From owner-freebsd-fs@FreeBSD.ORG Sat Jul 3 23:01:27 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 A5E1416A4CE; Sat, 3 Jul 2004 23:01:27 +0000 (GMT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72BB143D3F; Sat, 3 Jul 2004 23:01:27 +0000 (GMT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 5F63B5C82E; Sat, 3 Jul 2004 16:01:27 -0700 (PDT) Date: Sat, 3 Jul 2004 16:01:27 -0700 From: Alfred Perlstein To: "Tim J. Robbins" Message-ID: <20040703230127.GG95729@elvis.mu.org> References: <200407031322.i63DMdqC084182@repoman.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200407031322.i63DMdqC084182@repoman.freebsd.org> User-Agent: Mutt/1.4.2.1i 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: Sat, 03 Jul 2004 23:01:27 -0000 What are the implications of expanding the VFS API to take 64bit inodes? * Tim J. Robbins [040703 06:22] wrote: > tjr 2004-07-03 13:22:39 UTC > > FreeBSD src repository > > Modified files: > sys/conf NOTES files options > sys/fs/msdosfs msdosfs_vfsops.c msdosfs_vnops.c > msdosfsmount.h > sys/modules/msdosfs Makefile > Added files: > sys/fs/msdosfs msdosfs_fileno.c > Log: > 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. > > Don't enable this option unless you understand the consequences. > > Revision Changes Path > 1.1241 +12 -0 src/sys/conf/NOTES > 1.923 +1 -0 src/sys/conf/files > 1.460 +3 -0 src/sys/conf/options > 1.1 +163 -0 src/sys/fs/msdosfs/msdosfs_fileno.c (new) > 1.121 +14 -0 src/sys/fs/msdosfs/msdosfs_vfsops.c > 1.148 +33 -13 src/sys/fs/msdosfs/msdosfs_vnops.c > 1.33 +23 -1 src/sys/fs/msdosfs/msdosfsmount.h > 1.21 +4 -1 src/sys/modules/msdosfs/Makefile -- - Alfred Perlstein - Research Engineering Development Inc. - email: bright@mu.org cell: 408-480-4684