Date: Wed, 13 Nov 2002 23:17:53 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Tomas Pluskal <plusik@pohoda.cz> Cc: freebsd-fs@FreeBSD.ORG, <freebsd-hackers@FreeBSD.ORG>, <freebsd-current@FreeBSD.ORG> Subject: Re: seeking help to rewrite the msdos filesystem Message-ID: <20021113221729.N381-100000@gamplex.bde.org> In-Reply-To: <Pine.LNX.4.30L2.0211121047290.21366-100000@pohoda.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 12 Nov 2002, Tomas Pluskal wrote:
> I believe that everybody here knows about the "slow msdosfs" problem, that
> is AFAIK caused by implementation without clustering.
Which problem. msdosfs has a number of small problems. Mostly they don't
matter.
> For me this is very annoying, because I use digital camera, and ZIP drive,
> and FAT on both of them. Speed is about 10 times lower than it could be..
ZIP drives have much larger speed problems thn msdosfs. msdosfs happens
to be a good way to get the worst out of them. They have a minumum
i/o overhead of 20 msec (at least for all the 100MB ones that I tried),
so if you use msdosfs's minimum block size of 512 then their maximum
speed is 25K/sec which is about 40 times slower than it could be. The
default block size of 2K gives a speed which is about 10 times slower
than it could be. The ffs default block size of 16K gives a speed which
is only about 1.25 times slower than it could be. E.g.:
%%%
Script started on Wed Nov 13 22:13:53 2002
ttyv1:root@gamplex:/tmp> newfs /dev/afd0
/dev/afd0: 96.0MB (196608 sectors) block size 16384, fragment size 2048
using 4 cylinder groups of 24.02MB, 1537 blks, 3200 inodes.
super-block backups (for fsck -b #) at:
32, 49216, 98400, 147584
newfs: ioctl (DIOCWDINFO): /dev/afd0: can't rewrite disk label: Operation not supported by device
ttyv1:root@gamplex:/tmp> mount /dev/afd0 /mnt
ttyv1:root@gamplex:/tmp> dd if=/dev/zero of=/mnt/zz bs=1m count=20
time umount /mnt
20+0 records in
20+0 records out
20971520 bytes transferred in 18.827154 secs (1113898 bytes/sec)
ttyv1:root@gamplex:/tmp> time umount /mnt
0.29 real 0.00 user 0.02 sys
ttyv1:root@gamplex:/tmp> newfs_msdos -b 16384 /dev/afd0
/dev/afd0: 196512 sectors in 6141 FAT16 clusters (16384 bytes/cluster)
bps=512 spc=32 res=1 nft=2 rde=512 mid=0xf0 spf=24 spt=32 hds=64 hid=0 bsec=196608
ttyv1:root@gamplex:/tmp> mount -t msdosfs /dev/afd0 /mnt
ttyv1:root@gamplex:/tmp> dd if=/dev/zero of=/mnt/zz bs=1m count=20
time umount /mnt
20+0 records in
20+0 records out
20971520 bytes transferred in 27.729786 secs (756281 bytes/sec)
ttyv1:root@gamplex:/tmp> time umount /mnt
5.57 real 0.00 user 0.03 sys
ttyv1:root@gamplex:/tmp> exit
Script done on Wed Nov 13 22:16:06 2002
%%%
The above "could be" calculations are based on a speed of 1000K/sec. My
test drive can't quite reach this using raw reads with a block size of 64K,
but ffs clusters the data so well that it exceeds this speed for writes.
msdosfs with a block size of 16K achieves about 63% of this speed (not
the 87.5% suggested by the naive calculations).
My times are with some small improvements which I think don't affect
the tests much (they affect latency more than throughput). With lots
of small files (smaller than the block size), clustering doesn't makes
even less difference; however, msdosfs doesn't support soft updates
or async mounts so it it is about as slow as plain ffs (in my test of
writing 1000 files of size 512, msdosfs is actually only 5 times slower
than ffs with soft updates or async; plain ffs is about 7.5 times slower).
Bruce
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021113221729.N381-100000>