Date: Mon, 27 Nov 2006 15:23:45 +0100 (CET) From: Oliver Fromme <olli@lurza.secnetix.de> To: freebsd-stable@FreeBSD.ORG, security@jim-liesl.org Subject: Re: Large msdosfs disk will not mount on RELENG_6 Message-ID: <200611271423.kARENjD6035888@lurza.secnetix.de> In-Reply-To: <1164609934.3488.47.camel@emperor>
next in thread | previous in thread | raw e-mail | index | archive | help
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 -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200611271423.kARENjD6035888>