Large msdosfs disk will not mount on RELENG_6

Oliver Fromme olli at
Mon Nov 27 06:28:31 PST 2006

secmgr <security at> 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

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 Fromme,  secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD:
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.

(On the statement print "42 monkeys" + "1 snake":)  By the way,
both perl and Python get this wrong.  Perl gives 43 and Python
gives "42 monkeys1 snake", when the answer is clearly "41 monkeys
and 1 fat snake".        -- Jim Fulton

More information about the freebsd-stable mailing list