From owner-freebsd-hackers  Sun Feb  4 10:56:03 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id KAA22865
          for hackers-outgoing; Sun, 4 Feb 1996 10:56:03 -0800 (PST)
Received: from asgard.bga.com (asgard.bga.com [198.3.117.20])
          by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id KAA22849
          for <hackers@freebsd.org>; Sun, 4 Feb 1996 10:55:58 -0800 (PST)
Received: (from faulkner@localhost) by asgard.bga.com (8.7.3/8.7.3) id MAA07227; Sun, 4 Feb 1996 12:54:52 -0600 (CST)
From: Boyd Faulkner <faulkner@asgard.bga.com>
Message-Id: <199602041854.MAA07227@asgard.bga.com>
Subject: Re: FAT filesystem performance
To: luigi@labinfo.iet.unipi.it (Luigi Rizzo)
Date: Sun, 4 Feb 1996 12:54:52 -0559 (CST)
Cc: hackers@freebsd.org
In-Reply-To: <199602041410.PAA18920@labinfo.iet.unipi.it> from "Luigi Rizzo" at Feb 4, 96 03:10:36 pm
X-Mailer: ELM [version 2.4 PL24 ME8a]
Content-Type: text
Sender: owner-hackers@freebsd.org
Precedence: bulk

Before Terry has a fit :-) , let me tell you what he once told me.
One of the problems of implementing someone else's file system is 
error recovery.  If you cache FAT and your power goes out, for example,
the FAT on the disk is not consistent.  Aside from there being no fsck_msdos,
if you then booted up in DOS, your filesystem would be inconsistent, and
DOS doesn't like or expect that.  You can write a fast read-only FAT
FS but you have to fail as FAT would fail, to be truly compatible.

Did I get that right, Terry? :-)
Boyd

According to Luigi Rizzo:
> 
> 
> 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/
> ====================================================================
> 
> 


-- 
_____________________________________________________________________________

        Boyd Faulkner            "The fates lead him who will;
   faulkner@asgard.bga.com       Him who won't, they drag."
http://asgard.bga.com/~faulkner  Old Roman Saying -- Source:  Joseph Campbell
_____________________________________________________________________________