From owner-freebsd-hackers Sun Feb 4 13:50:58 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA09451 for hackers-outgoing; Sun, 4 Feb 1996 13:50:58 -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 NAA09446 for ; Sun, 4 Feb 1996 13:50:55 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA06143; Sun, 4 Feb 1996 14:48:27 -0700 From: Terry Lambert Message-Id: <199602042148.OAA06143@phaeton.artisoft.com> Subject: Re: FAT filesystem performance To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Sun, 4 Feb 1996 14:48:27 -0700 (MST) Cc: hackers@FreeBSD.ORG In-Reply-To: <199602041410.PAA18920@labinfo.iet.unipi.it> from "Luigi Rizzo" at Feb 4, 96 03:10:53 pm 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 > Some time ago there was a discussion on the performance of FAT > filesystems. I think the conclusion was that it is not intrinsically > slow, it is just a problem of non optimal implementations which > tend not to keep the FAT in memory, and perhaps use synchronous writes. My conclusion has always been that it is intrinsically slow. The big "wins" on the MACH FAT implementation come from intentionally crippling UFS (disabling caching, etc.) and then caching the whole FS and directory structure for FAT. And even then, FAT doesn't do that well. > Additionally, performance might probably benefit by an allocation > policy which privileges contiguity and locality for the blocks > belonging to the same file. This is a tradeoff between read speed and write speed whenever you implement it. > We use FAT filesystems both in the kernel, and in mtools. > For the latter, I thought there was a quick fix to the problem of > caching the FAT: just mmap the device, and the kernel will do caching > for you. Well, it does not look that simple, as the vast majority of > raw devices does not support mmap. > > I am wondering: how hard would it be to add mmap() to, say, wd.c ? > Would it have other useful applications ? This would be useful for mtools, but not for the kernel version of FAT. The FAT-caching in the MACH implementation (you *could* just port the MACH code...) takes a significant amount of memory, IMO. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.