Date: Wed, 13 Nov 2002 03:05:15 -0800 From: David Schultz <dschultz@uclink.Berkeley.EDU> To: Tomas Pluskal <plusik@pohoda.cz> Cc: Terry Lambert <tlambert2@mindspring.com>, freebsd-fs@FreeBSD.ORG Subject: Re: seeking help to rewrite the msdos filesystem Message-ID: <20021113110515.GA6287@HAL9000.homeunix.com> In-Reply-To: <Pine.LNX.4.30L2.0211130955140.13142-100000@pohoda.cz> References: <Pine.LNX.4.30L2.0211130955140.13142-100000@pohoda.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
Thus spake Tomas Pluskal <plusik@pohoda.cz>: > > This has more to do with sequential access. Technically, you can > > read a FAT cluster at a time instead of an FS block at a time, and > > you will achieve some multiplier on sequential access, but you will > > find that under load, that the fault rate for blocks will go up. > > When I read from my ZIP drive, according to iostat the request size is > 2KB. When I run dd with 2KB request size: > > # dd if=/dev/afd0 of=/dev/null bs=2048 count=100 > 100+0 records in > 100+0 records out > 204800 bytes transferred in 2.127448 secs (96266 bytes/sec) > > If I understand this right, I can never get faster then 96KB/s with > sequential access, when using 2KB requests ? It is quite slow :) Terry's main point, I think, is that if you just request extra blocks from the disk when you do a read without thinking about it, you will only be improving performance for a defragmented FAT FS with few concurrent accesses. In the presence of fragmentation, which FAT is highly susceptible to, it's likely that the read ahead will fetch the wrong block and merely waste time and space. It's not as simple as ``2K requests are slow, but 16K requests are fast.'' The crucial difference is that in FFS, once you've cached the inode and any indirect blocks, you know exactly how logical positions in the file map to physical disk locations. Moreover, blocks of a given file are usually grouped together, so clustering is a reasonable thing to do. In FAT, you have to fetch the first N-1 blocks of the file before you know where the Nth block is on disk. Reading ahead is a way of speculating, which may or may not be beneficial, as described above. That said, I wouldn't mind if someone was willing to fix up the msdosfs stuff. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021113110515.GA6287>