Re: Filesystem for mobile hard drive
From: Nicolas George
Date: Sun Feb 12 2006 - 20:05:20 EST
Le quartidi 24 pluviôse, an CCXIV, Phillip Susi a écrit :
> If by FAT you mean FAT16, then yes, you have an 8 GB limit for the
> entire filesystem. Fat32 on the other hand, can handle much more and so
> should be suitable in this aspect.
According to Wikipedia, and what I knew besides, FAT32 has a limit of 2 To
for the whole filesystem. But the limit I was talking of is the file size
limit: 4 Go perfile. Which is, nowadays, a bit short: an ISO image for a
DVD-R does not fit, for example.
> Fragmentation is also a property not
> of the filesystem, but of Microsoft's filesystem drivers. I'm fairly
> sure that the linux fat implementations do not use absurdly stupid
> allocation algorithms that lead to lots of fragmentation.
I am not sure about that: you can not do really good algorthms on bad data
structures, and the data structures of FAT do not provide any support to do
> This can be overcome with the UDF filesystem by using the uid and gid
> mount options, allowing the files to appear to be owned by the correct
> local user.
That is interesting. Do you know how efficient UDF is compared to others
filesystems on normal hard drives? It is optimized for CDs and DVDs, I would
not be surprised if the performances were poor on different supports.
> It would be nice if the other filesystems were patched to
> allow such options as well.
I believe that such options should not be done on a per-filesystem basis.
Something in the common code of the VFS would be more logical.
> Network filesystems are not on disk filesystems, so they have nothing to
> do with this discussion; you can't format a disk as "nfs" or "smb".
The idea was to mount the disk with its haphazard UIDs, and then export it
and mount it as a network filesystem over the loopback. By itself, it is
absolutely useless, but networked filesystems have UIDs mapping facilities.
Description: Digital signature