Date: Tue, 12 Nov 2002 16:28:07 -0800 From: David Schultz <dschultz@uclink.Berkeley.EDU> To: Terry Lambert <tlambert2@mindspring.com> Cc: Tomas Pluskal <plusik@pohoda.cz>, freebsd-fs@FreeBSD.ORG Subject: Re: seeking help to rewrite the msdos filesystem Message-ID: <20021113002807.GA4711@HAL9000.homeunix.com> In-Reply-To: <3DD14AD9.DF8D3580@mindspring.com> References: <20021112134213.P32524-100000@localhost> <3DD14AD9.DF8D3580@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Thus spake Terry Lambert <tlambert2@mindspring.com>: > 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. > > Also, even if you read 64K at a time, you will end up LRU'ing out > the data that you don't access. > > The issue is that UNIX files are accessed by offset, and FAT files > are accessed by offset by chaining clusters from the start to the > cluster of interest, and then reading blocks. Few people use FAT filesystems under heavy load as they do UFS. Basically, I think what he wants to do is speed up sequential reads for a single process doing, say, digital video editing. On a FAT FS that is relatively free of fragmentation, naïve read-ahead is likely to improve performance for this type of load, even though the next logical block in the file might not be the next physical block on the disk. IIRC, SMARTDRV does this. This approach is optimizing for the single-user case, but if you have several people using a single FAT FS at a time, you have much bigger problems. 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?20021113002807.GA4711>