Re: Filesystem for mobile hard drive

[Nicolas George <nicolas.george@ens.fr>]

[-- Attachment #1: Type: text/plain, Size: 1991 bytes --]

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
smart allocation.

> 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.


Regards,

-- 
  Nicolas George

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 185 bytes --]