Path: utzoo!mnetor!uunet!husc6!bbn!rochester!cornell!batcomputer!itsgw!imagine!pawl14.pawl.rpi.edu!jesup
From: jesup@pawl14.pawl.rpi.edu (Randell E. Jesup)
Newsgroups: comp.sys.amiga
Subject: Re: Large hard disks for Amiga
Message-ID: <518@imagine.PAWL.RPI.EDU>
Date: 12 Mar 88 07:04:13 GMT
References: <7541@oberon.USC.EDU> <3822@cup.portal.com>
Sender: news@imagine.PAWL.RPI.EDU
Reply-To: beowulf!lunge!jesup@steinmetz.UUCP
Organization: RPI Public Access Workstation Lab - Troy, NY
Lines: 27

In article <3822@cup.portal.com> th@cup.portal.com writes:
>So where does the 50MB limit come from?  Simple.  Get out your calculators.
>Look at the format of the root block: there is a list of 26 "pointers" to
>the bit map pages.  Each bitmap "page" has 127 longwords of bits and one
>longword of checksum.  Each longword has 32 bits.  So: 26*127*32 is the
>LIMIT to the numbers of sectors AmigaDOS can handle on a hard disk.
...
>WHY isn't the list of bit maps an open-ended chain?  Haven't heard that
>the alleged "Fast File System" (FFS) will correct this glaring deficiency;
>does anybody KNOW if it will?

	I've said this before, but....  They tried to fix the bitmap page
limit in 1.2.  I think the last link is to another page of bitmaps, etc.
Unfortunately, another new thing in 1.2, the archive bit, happens to live
where they put the pointer, if it were a directory block instead of the
root.  So when you change something in the root, the link to the next block
of bitmaps gets trashed.  Oh well.

	The FFS (coming in 1.3, in Gamma test now) is 1) FAST!  up to 600+
Kbytes/sec, and 2) fixes the partitioning problem, max partition in 2 gig.

     //	Randell Jesup			      Lunge Software Development
    //	Dedicated Amiga Programmer            13 Frear Ave, Troy, NY 12180
 \\//	beowulf!lunge!jesup@steinmetz.UUCP    (518) 272-2942
  \/    (uunet!steinmetz!beowulf!lunge!jesup) BIX: rjesup

(-: The Few, The Proud, The Architects of the RPM40 40MIPS CMOS Micro :-)