hmmm... any numbers ?
Quick test umsdos partition with ~150 MB free:
cp -a /usr/local/bin/* /trans/test 006s user 280s system 65% cpu 4399 total
cp -a /usr/local/bin/* /trans/test 005s user 264s system 71% cpu 3740 total
Quick test ext2 on loopbacked 100MB image on VFAT partition (same IBM DHEA disk)
cp -a /usr/local/bin/* /mnt 005s user 407s system 73% cpu 5580 total
cp -a /usr/local/bin/* /mnt 005s user 425s system 95% cpu 4483 total
It seems that at least in this quick comparision UMSDOS is faster.
machine is dual P-200 MMX, 64MB RAM. kernel is 2.1.126.
/usr/local/bin is ~22MB in 152 files.
Tested as fresh reboot, test1, rm files, test2.
Then reboot again, and same for ext2 loopbacked on VFAT.
>My analysis indicates that the really slow section of the UMSDOS
>driver is its filename translation routine, although I'm not sure why.
I don't see why it would be slowest part of umsdos.
It is not that much different than VFAT mangling for short names.
>That's why I suggested using VFAT as the underlying file system rather
>than MSDOS - it eliminates that routine completely since VFAT can
>already handle long filenames, so doesn't need it.
It does use division 2 times per filename, which could be replaced
by shifting at little expense of code readibily. Probably should be.
check the fs/umsdos/mangle.c
Also mangling code is using only on file lookup/creation, which should not
be big percentage of time spent. Most time is spent on block read/write
request, where umsdos should be faster (it is calling fat_mapping functions
directly), whereas ext2 over loopback over vfat should first use
ext2_mapping, and then loopback_mapping, and then fat_mapping.
-- Opinions above are GNU-copylefted.- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/