Date: Sat, 24 May 1997 23:02:11 +1000 From: Bruce Evans <bde@zeta.org.au> To: current@FreeBSD.ORG, j@uriah.heep.sax.de Subject: Re: cd9660 filesystem slowed down ??? Message-ID: <199705241302.XAA06875@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>j@uriah 145% dd if=/cdrom/xxxx of=/dev/null >13036+1 records in >13036+1 records out >6674533 bytes transferred in 70.361082 secs (94861 bytes/sec) There is a stranger anomaly for ext2fs with an fs block size of 1K: Immediately after mounting: $ dd if=libg++.a >/dev/null 3656+1 records in 3656+1 records out 1872034 bytes transferred in 4.143877 secs (451759 bytes/sec) This is normal - the drive is a Zip with a best case transfer speed of about 1MB/sec. Second run: $ dd if=libg++.a >/dev/null 3656+1 records in 3656+1 records out 1872034 bytes transferred in 29.836025 secs (64264 bytes/sec) Subsequent runs: about the same speed as the second run 60-70K/sec. This has something to do with nbuf (= 0x6a5) * fs_block_size (= 1K) being slightly less than the file size. For smaller files, caching gives a 20 times speed improvement instead of a 7 times speed unimprovement. Reading with a 4K block size doesn't help much. Caching works even less well for writing to this file system: $ dd if=/dev/zero of=z bs=1k count=1400 1400+0 records in 1400+0 records out 1433600 bytes transferred in 42.815710 secs (33483 bytes/sec) $ [same with count=1000] 1024000 bytes transferred in 28.514967 secs (35911 bytes/sec) $ [same with count=600] 614400 bytes transferred in 13.807223 secs (44498 bytes/sec) $ [same with count=200] 204800 bytes transferred in 0.047537 secs (4308226 bytes/sec) ext2fs with a block size of 4K seems to work fine. So does msdosfs with a block size of 4K. Note that msdosfs doesn't use cluster_read(). cd9660 with doclusterread turned off is even slower than with it on, so I assume that this is a general caching problem. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199705241302.XAA06875>