home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!portal!lll-winken!iggy.GW.Vitalink.COM!cs.widener.edu!hela.iti.org!usc!zaphod.mps.ohio-state.edu!sample.eng.ohio-state.edu!purdue!yuma!csn!teal!bazyar
- From: bazyar@teal.csn.org (Jawaid Bazyar)
- Newsgroups: comp.sys.apple2
- Subject: Re: GS/OS FST
- Message-ID: <bazyar.720987514@teal>
- Date: 5 Nov 92 18:18:34 GMT
- References: <AWILLIS.92Nov1041412@posse.mit.edu> <73965@apple.Apple.COM> <1992Nov5.051205.22724@nuscc.nus.sg> <1992Nov5.101520.4744@klaava.Helsinki.FI>
- Sender: news@csn.org (news)
- Organization: Colorado SuperNet, Inc.
- Lines: 26
- Nntp-Posting-Host: teal.csn.org
-
- cust_ts@klaava.Helsinki.FI (Tero Sand) writes:
-
- >I understood from Matt Deatherage's (sp?) article(s) that by the time
- >everything you people want gets added to the GSOS FST, it essentially
- >*is* an HFS FST.
-
- Not quite. Maintaining BTrees is CPU intensive. I'd be happy with
- a linear directory structure (like ProDOS) but with greatly increased
- throughput.
-
- >Not true. Copying & shuffling with directories is, yes, sometimes, but
- >launching applications seems to be faster. With me, at least.
-
- But the Berkeley Fast Filesystem is FAST. REALLY FAST. That's what
- I'm after. The BFFS takes into account drive parameters like head
- latency, rotation time, rotations/second, etc to calculate exactly how
- to lay stuff out on the drive. In a sense, it's always adjusting the
- interleave for optimum performance. It also does some other highly
- smart things (like blocks bigger than 512 bytes) for increased
- throughput.
-
- --
- Jawaid Bazyar | Ask me about the GNO Multitasking Environment
- Procyon, Inc. | for the Apple IIgs!
- bazyar@cs.uiuc.edu | P.O Box 620334
- --Apple II Forever!-- | Littleton, CO 80162-0334 (303) 933-4649
-