Date: Sun, 4 Feb 1996 14:48:27 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Cc: hackers@FreeBSD.ORG Subject: Re: FAT filesystem performance Message-ID: <199602042148.OAA06143@phaeton.artisoft.com> In-Reply-To: <199602041410.PAA18920@labinfo.iet.unipi.it> from "Luigi Rizzo" at Feb 4, 96 03:10:53 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602042148.OAA06143>