From owner-freebsd-fs Tue Nov 12 3:10:34 2002 Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4894337B404 for ; Tue, 12 Nov 2002 03:10:29 -0800 (PST) Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6484143E42 for ; Tue, 12 Nov 2002 03:10:29 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0020.cvx21-bradley.dialup.earthlink.net ([209.179.192.20] helo=mindspring.com) by swan.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18BYw5-0005I5-00; Tue, 12 Nov 2002 03:10:26 -0800 Message-ID: <3DD0E002.914DA5EF@mindspring.com> Date: Tue, 12 Nov 2002 03:03:30 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Tomas Pluskal Cc: freebsd-fs@freebsd.org Subject: Re: seeking help to rewrite the msdos filesystem References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Tomas Pluskal wrote: > I believe that everybody here knows about the "slow msdosfs" problem, that > is AFAIK caused by implementation without clustering. No; mostly it's non-page aligned accesses, and the fact that serial access requires traversal of the entire file up to that point, and so becomes exponential, the further you get into the file. See: http://www.usenix.org/publications/library/proceedings/sf94/forin.html The intent of this paper was to make the DOS FS look good, by caching all FAT metadata, and disabling all normal OS caching in the FFS implementation. However, it does have a couple of good suggestions for speeding FAT file access up. The most useful is that you should cache the metadata information, so that you can traverse the list of FS blocks in memory, instead of on disk, and caching of all the directory information (for the same reasons). Because the directory entry is also the inode, in FAT, this has the effect of caching all the inodes, as well. If you want to get fancy, then you would implement the metadata cachine for file blocks as a btree, so that you could go to a given block in log2(# of blocks) compares, in memory, instead of spending a long time traversing sectors. > 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.. > I would like to rewrite the msdosfs driver to use clustering (in fact, I > have chosen it as school project, so I have to do it anyway :). > > Is there anybody, who could spend few minutes and write me some > information about how these filesystems are implemented, what should I > read first, and what steps to follow to implement clustering ? > I am ready to do the hard work :) I don't think the issue is actually clustering. If the cluster size is set, you really don't have a choice, since your block chain is hung off that, so it's not like FreeBSD goes out of its way to pessimize access. As far as alignment goes, make sure the MSDOSFS starts on a 4K boundary, and you should be OK; otherwise, every 4th one is going to span a page boundary, and you'll eat a page-in latency over it; this is less common these days, but it really depends on your ZIP disk partition layout (in most cases, there's an assumption of 64K per cylinder/head these days, and 64K is evenly divisible by 4K, which equals no alignment problem). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message