Date: Mon, 27 Nov 2006 11:21:42 -0500 From: Richard Coleman <rcoleman@criticalmagic.com> To: freebsd-stable@FreeBSD.ORG, security@jim-liesl.org Subject: Re: Large msdosfs disk will not mount on RELENG_6 Message-ID: <456B1096.3000702@criticalmagic.com> In-Reply-To: <200611271423.kARENjD6035888@lurza.secnetix.de> References: <200611271423.kARENjD6035888@lurza.secnetix.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Oliver Fromme wrote: > secmgr <security@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@criticalmagic.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?456B1096.3000702>