From owner-freebsd-hackers Sun Feb 4 06:10:41 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA04313 for hackers-outgoing; Sun, 4 Feb 1996 06:10:41 -0800 (PST) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id GAA04304 for ; Sun, 4 Feb 1996 06:10:37 -0800 (PST) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id PAA18920 for hackers@freebsd.org; Sun, 4 Feb 1996 15:10:53 +0100 From: Luigi Rizzo Message-Id: <199602041410.PAA18920@labinfo.iet.unipi.it> Subject: FAT filesystem performance To: hackers@freebsd.org Date: Sun, 4 Feb 1996 15:10:53 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text 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. Additionally, performance might probably benefit by an allocation policy which privileges contiguity and locality for the blocks belonging to the same file. 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 ? Thanks Luigi ==================================================================== Luigi Rizzo Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it Universita' di Pisa tel: +39-50-568533 via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 http://www.iet.unipi.it/~luigi/ ====================================================================