Date: Mon, 5 Feb 1996 12:51:12 +0200 (SAT) From: Robert Nordier <rnordier@iafrica.com> To: bde@zeta.org.au (Bruce Evans) Cc: hackers@freebsd.org Subject: Re: FAT filesystem performance Message-ID: <199602051051.MAA04211@eac.iafrica.com> In-Reply-To: <199602050734.SAA02716@godzilla.zeta.org.au> from "Bruce Evans" at Feb 5, 96 06:34:42 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > The new MS-DOS [ie. DOS 2.0] does not keep the file > > allocation tables in memory at all times. Instead the > > tables share the use of sector buffers.... This change > > in the DOS goes completely against my original design > > principles.... Now we're back to doing disk reads just > > to find out where the data is. > > -- Tim Paterson, Byte, June 1983. > > I wonder if he thought about maximal FATs with 64K * 1.5 byte entries. > They would barely fit on a 160K floppy :-). That's true. I think if he'd been writing a few years later -- and not so much in the context of floppies and 10M/20M MFM drives -- he might even have decided differently.... And if he'd been writing now, maybe differently again. :-) Point is, though, historically the DOS file system implementation developed under one set of constraints; I think an efficient implementation on *BSD needs to (at least) consider a different set. IMO, an attempt to merely "do as DOS does" (for better or for worse) is not a workable design principle for re-implementing the msdosfs. Though I also guess that this sort of intentional hair-splitting -- while it seems useful to me -- is of really minimal interest, so I'll drop it here. > 128K is quite small now, but it still isn't necessary to lock it into > memory. Caching it in a normal LRU way should work reasonably well. > Perhaps FAT buffers should have a higher priority than other buffers > for msdosfs, but they probably shouldn't have higher priority than > buffers for other file systems. I'd go along with that: and certainly not the msdosfs at the expense of other fs-es. One thing they did find with the MS-DOS LRU scheme was that FAT sectors tended to "un-cache" too readily. Different prioritization could resolve that. In practice, though, it always seems comparatively hard to predict just how any optimization strategy is going to pan out. Ideally I'd vote to keep the stuff generally very configurable, and then vote again finally from the numbers. If benchmarks ceased entirely to be surprises, people would mostly stop running them. :-) -- Robert Nordier
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602051051.MAA04211>