Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 5 Feb 1996 03:30:51 +0200 (SAT)
From:      Robert Nordier <rnordier@iafrica.com>
To:        hackers@freebsd.org
Subject:   Re: FAT filesystem performance
Message-ID:  <199602050130.DAA02768@eac.iafrica.com>
In-Reply-To: <199602041854.MAA07227@asgard.bga.com> from "Boyd Faulkner" at Feb 4, 96 12:54:52 pm

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 4 Feb 1996, Boyd Faulkner wrote:

> 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.

The bottom line is that a FAT fs should cache in such a way that the
tradeoff between performance and safety is acceptable.  But this is a
matter of dealing sensibly and appropriately with the data structures,
not of imitating the worst aspects of another implementation.

If you (potentially) make certain messes, then you ensure they can be
cleaned up to the extent that redundancy in the structures permits this.
(If they don't permit this very well, you may have made a bad tradeoff.)
If existing recovery tools are partially inadequate, you supplement them.

The aim isn't to ape DOS, make the same mistakes as DOS, or fail like DOS.
The aim is good design; and the same considerations apply whether the fs
is shared with DOS or not.  If the algorithms end up similar for the same
structures, that should be due to similar design tradeoffs, not DOS copying
or emulation.

DOS FAT failures (in totality) are not idiosyncratic; and even if they were,
the "fix" is in supplementing recovery tools, not in a crippled fs design.

-- 
Robert Nordier



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602050130.DAA02768>