Date: Tue, 6 Jul 2004 09:11:19 -0700 From: Mark Day <mday@apple.com> To: "Tim J. Robbins" <tjr@freebsd.org> 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 Message-ID: <1DC8D54A-CF67-11D8-BF9F-000A95D99E06@apple.com> In-Reply-To: <20040703230127.GG95729@elvis.mu.org> References: <200407031322.i63DMdqC084182@repoman.freebsd.org> <20040703230127.GG95729@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1DC8D54A-CF67-11D8-BF9F-000A95D99E06>