home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!dtix!darwin.sura.net!news.udel.edu!bach.udel.edu!lecates
- From: lecates@bach.udel.edu (Roy LeCates)
- Newsgroups: comp.sys.apple2
- Subject: Re: gs.os.FST?
- Message-ID: <Bt6rC5.404@news.udel.edu>
- Date: 18 Aug 92 15:36:04 GMT
- References: <fmlin.163u@terapin.com>
- Sender: usenet@news.udel.edu
- Organization: University of Delaware
- Lines: 29
- Nntp-Posting-Host: bach.udel.edu
-
- In article <fmlin.163u@terapin.com> fmlin@terapin.com (Frank M. Lin) writes:
-
- >GS/OS is flexible enough to allow FSTs, I am wondering why we have to deal with
- >HFS? I mean, I find accessing HFS is noticibly slower when compared to prodos
- >volumes. I have 3 32mb prodos and 1 105+mb HFS. HFS is slow!
-
- HFS is a much more complicated file system, thus inherently slower.
-
- >Why can't there be a simple new "gs.os.FST" be written. It should be as
- >similar to prodos a possible ( easier to program? ), just remove the 32mb
- >limit.
-
- That's an interesting thought, but then no Prodos 8 programs would be able
- to access the volume. Even worse, programs that do not use all standard
- GS/OS calls might have a LOT of trouble using the volume.
-
- >Although, now that I got my twgs back, accessing my HFS volume seem to have
- >speed up a lot! So, having a twgs or zip will help HFS access time?
-
- I'm sure that the slowness comes from the CPU not the drive. Since the
- drive can read/write quickly, there's no slow down. However, the CPU must
- contend with all of the HFS file system maintenance (a laborious task),
- so a faster CPU will natually speed data transfer.
-
- --
- ------------------------------------------------------------------
- Roy M. LeCates EE Undergraduate lecates@bach.udel.edu
- University of Delaware Electrical Engineering and Computer Science
- ------------------------------------------------------------------
-