From owner-freebsd-stable@FreeBSD.ORG Mon Nov 27 16:21:43 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7AA1716A47B for ; Mon, 27 Nov 2006 16:21:43 +0000 (UTC) (envelope-from rcoleman@criticalmagic.com) Received: from mailserver1.internap.com (mailserver1.internap.com [63.251.68.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id E08F943D4C for ; Mon, 27 Nov 2006 16:20:41 +0000 (GMT) (envelope-from rcoleman@criticalmagic.com) Received: from [63.251.67.9] (account rcoleman@mail.internap.com HELO [63.251.67.9]) by mailserver1.internap.com (CommuniGate Pro SMTP 4.2.10) with ESMTP id 73434076; Mon, 27 Nov 2006 11:21:42 -0500 Message-ID: <456B1096.3000702@criticalmagic.com> Date: Mon, 27 Nov 2006 11:21:42 -0500 From: Richard Coleman Organization: Critical Magic, Inc. User-Agent: Thunderbird 1.5.0.7 (X11/20061107) MIME-Version: 1.0 To: freebsd-stable@FreeBSD.ORG, security@jim-liesl.org References: <200611271423.kARENjD6035888@lurza.secnetix.de> In-Reply-To: <200611271423.kARENjD6035888@lurza.secnetix.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Large msdosfs disk will not mount on RELENG_6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2006 16:21:43 -0000 Oliver Fromme wrote: > secmgr 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