From owner-freebsd-hackers Mon Feb 5 12:25:57 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA20809 for hackers-outgoing; Mon, 5 Feb 1996 12:25:57 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA20804 for ; Mon, 5 Feb 1996 12:25:55 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA14247; Mon, 5 Feb 1996 13:22:59 -0700 From: Terry Lambert Message-Id: <199602052022.NAA14247@phaeton.artisoft.com> Subject: Re: FAT filesystem performance To: joerg_wunsch@uriah.heep.sax.de Date: Mon, 5 Feb 1996 13:22:59 -0700 (MST) Cc: freebsd-hackers@FreeBSD.org In-Reply-To: <199602050135.CAA02717@uriah.heep.sax.de> from "J Wunsch" at Feb 5, 96 02:35:35 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org Precedence: bulk > If you wanna improve the FAT file system implementation, first study > its bottlenecks. The msdosfs code could certainly be improved in > terms of robustness and performance. Since it's kernel-level, it has > full control over what kind of buffers it will allocate, either > pageable or non-pageable. I think the biggest win would be a 512b buffer validity granularity. That is, an 8 bit bitmap for pages indicating which disk blocks in a given page are in fact valid. This would save significantly in read overhead for sequential rewrite of an existing file, or random write of records of less than half the page size. The VM modifications would not be insignificant. One of the biggest bottlenecks in the Linux MSDOSFS was the 1k read granularity in the disk driver causing significant read overhead for the actual on disk block/cluster I/O. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.