Large msdosfs disk will not mount on RELENG_6

[Richard Coleman]

Oliver Fromme wrote:
> secmgr <security at jim-liesl.org> wrote:
>  > 
>  > > As far as I am aware windows 2000 and xp will only allow you to format up to 
>  > > a 32G dive with FAT32. Any bigger and it will force you to use NTFS. The 
>  > > other strange thing is tht you are trying to mount /dev/da0 and not 
>  > > /dev/de0s1.
>  > 
>  > The 32 gb restriction was artificial.  You can look it up in the M$
>  > "knowledge" base.  Watch out for the hand waving.  FreeBSD and Linux
>  > (and probably other cluefull OS's)can handle a 500gb FAT32 drive
>  > (assuming intelligent format values) w/o problem.
>
> That's not completely correct, at least as far as FreeBSD
> is concerned (I don't know if and how Linux solves the
> problem).
>
> The basic problem is that FAT doesn't support what UNIX
> calls "inode" numbers (sometimes also called "fileid").
> But for a file system to be able to be handled under Free-
> BSD (and other UNIX systems), files have to be uniquely
> identified by such inode numbers.  To solve that problem,
> FreeBSD's msdosfs uses a simple hack by assigning a number
> to each file based on the offset of its directory entry
> relative to the beginning of the file system.
>
> However, if the size of the file system exceeds 128 MB
> (which is the size of 2^32 directory entries), then those
> numbers don't fit into a 32 bit inode number anymore.
> If you try to mount such a file system, it will fail and
> print the error message "disk too big, sorry".
>
> If you compile your kernel with MSDOSFS_LARGE, then the
> kernel uses a different hack to generate appropriate inode
> numbers:  Whenever you access a file, it assigns a number
> dynamically for this file.  That approach works for FAT
> file systems of unlimited size, but it has two other draw-
> backs:  First, the kernel needs to maintain a table for
> mapping between files and inode numbers.  So, if the file
> system contains many files, the kernel will need a huge
> amount of kernel memory which won't be freed until the FS
> is unmounted (and if you run out of kernel memory, your
> machine panics).  Second, when you unmount and remount the
> same file system, you might get different inode numbers
> for your files (because of the dynamic nature), which can
> confuse certain applications.  In particular it breaks NFS
> because NFS -- being a stateless protocol -- requires
> constant inode numbers for exports.
>
> Best regards
>    Oliver
>   
Thanks for the explanation.  That helps a lot.

Because of the potential panics that were mention, I can understand a 
reluctance to change the default.  But I suspect that (attempting to) 
mount a large msdosfs disk is a much more common occurrence than using a 
smaller msdosfs disk over NFS.

Richard Coleman
rcoleman at criticalmagic.com