> Seeks on a FAT32 disk are, if you cache the entire FAT table, linear
> in time depending on the file position.

..all depends on how smart is your filesystem driver. I will not argue on
specific ones, however, wrote several FAT or FAT-like filesystem drivers and
can tell you that you can do lots of speed enforcements so you will not able
to tell by the speed that a particular file is stored on an NTFS or FAT.

> The file system has no support
> for avoiding fragmentation and thereby requires defragmentation.

again, depends on the driver, but do not forget that FAT was designed as
simple as possible, so nobody wanted to write a driver that took care of
fragmentation. Today in a digital camera for example you could rely on three
things:

1. you take lots of pictures with the same settings which needs almost the
same size of each, so when you delete one picture you can store the next one
to the same place.

2. you delete all files from time to time from your media, so the entire
system will be unoccupied so the new entries will be placed in unfragmented
areas

3. you will not update files too often as there is no database or the like
so you do not need to insert new records or append to the same file from
time to time.

So why would you use other filesystem? You do not need journaling, you do
not need volume management, you do not need ACL or anything like that. You
just need to store the pictures / music files statically and use them as it
is.

On a PC or a Mainframe I agree that you need something more sophisticated
but basically the binary structure of a filesystem is nothing if the driver
does not use it right. My problem with the NTFS is that even though that has
a root to HPFS MS keeps it propriety so nobody could write an official
driver for it so everybody is having the risk that Microsoft makes changes
on its binary structure without any further notification.

Tamas
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist