Oliver Fromme wrote:
secmgr <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED]
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
