From: daveh@cbmvax.commodore.com (Dave Haynie)
Newsgroups: comp.sys.amiga.advocacy
Subject: Re: HPFS Re: Amiga file system
Date: 18 Aug 92 00:25:17 GMT
Reply-To: daveh@cbmvax.commodore.com (Dave Haynie)
Organization: Commodore, West Chester, PA

In article <1992Aug17.193150.13579@grebyn.com> richk@grebyn.com (Richard Krehbiel) writes:
>In article <1992Aug17.051631.17025@usl.edu> das9674@usl.edu (Stephenson Daniel A) writes:
>>Can anyone tell me the fundamental differences between the
>>Amiga file system, and the OS/2 2.0 High Performace File System?

>HPFS has a maximum file name length of 255 characters, with any number
>of intervening dots.  AmigaDOS file names are smaller, I'm not sure,
>but I think 32 characters. (Subjective: I always found 32 long enough.)

Amiga OFS/FFS file names are limited to 31 characters or so.  I believe AmigaDOS
limits them to 255 characters.  Take the shortest of the AmigaDOS and FileSystem
limits to figure out your personal working limit.

>HPFS uses a structure called a "B-tree" to organize a directory.  This
>is a scheme which keeps directory entries in alphabetic order, and
>makes lookups quick.  

I believe that's similar to the Mac's filesystem (I think it uses B+ trees, but
the same basic idea).  That seems (to me as a user of the Mac) to make things
like directory (icon) listings fast, lots of other file operations very slow.

>AmigaDOS uses a "hash table" to organize a directory, which makes direct 
>lookups quick but intentionally randomizes the order in which directory 
>entries occur.

Alphabetically speaking, they're randomized, but for a Workbench display you
don't care.  Actually, for a sorted CLI directory listing you really don't
care either, since sorting takes a barely measurable amount of time compared
to any kind of disk seeking.

>Retrieval of all entries in an HPFS directory is quick because the
>B-tree keeps the directory entries close together on disk.  Retrieval
>of all entries in an AmigaDOS directory is comparatively very slow;
>the unpredictable placement of file directory entries on the disk
>requires a lot of seeking.

FFS stores small files, like icon files, close to their parent, and sorts
all hash collisions in disk order.  This doesn't make for listings as fast
as some other filesystems, but it's a far cry from OFS under 1.2.  You
may see much improved algorithms in the future, though, even for listing
files.  Another difference that's not real obvious between the typical Amiga
system and typical PC system that affects this is the hard disk interface.
IDE tends to be faster than Amiga SCSI at small transfers, and much slower at
large transfers.  Directory listings involve many small transfers.

>Extended attributes are a source of trouble for OS/2 backup programs, 
>because you must use special access methods to manipulate them, 

Eeek.  This sounds suspiciously like Mac resource forks.  A shame,
really, since it's trivial to have your cake and eat it too in such a
case.  While I don't know of anyone doing it, rather than have a filesystem
with specifically hidden forks like this, you could have a filesystem that
allowed any file to contain an association link to another file.  This would
make it easy for a file to access its primary resource fork, yet let that 
exist as a first class file on its own.  The filesystem could stop to make
the association for you when files are created.

-- 
Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      BIX: hazy
	"Work like a horse, drink like a fish"	- Psychefunkapus
 
Newsgroups: comp.sys.amiga.advocacy