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

[Mark Day]

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