Path: utzoo!attcan!uunet!cbmvax!jesup
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.sys.amiga.tech
Subject: Re: max hd capacity
Keywords: hard disk, maxtor
Message-ID: <14938@cbmvax.commodore.com>
Date: 8 Oct 90 01:39:42 GMT
References: <1261@romana.Tymnet.COM> <14805@cbmvax.commodore.com> <6696@sugar.hackercorp.com> <1990Oct4.012859.8522@agora.uucp> <14936@cbmvax.commodore.com>
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Distribution: na
Organization: Commodore, West Chester, PA
Lines: 28

In article <1990Oct4.012859.8522@agora.uucp> billsey@agora.uucp (Bill Seymour) writes:
>	Wouldn't there be some sort of limit to the largest logical block
>number accessed through SCSI? According to my Maxtor XT-3000S manual (The
>only thing I have handy right now...) a SEEK command only allows logical
>block numbers up to 24 bits long, and a SEEK EXTENDED only allows logical
>block numbers up to 32 bits long. That means in SCSI I implementations,
>you're limited to about 4G blocks, or 2T byte drives. Of course, with a
>2T drive, you could have 1K partitions of 2G each... The problem here is
>that typically, a 2T drive only uses LUN 0, and doren't support higher
>LUNs. That means you're limited to 7K, 2G partitions. :-(

	Ah, but you're assuming 512 byte blocks.  SCSI blocksize can be
anything, and the 2.0 FS can handle power-of-two blocksizes up to some limit,
like 32KB.  BTW, Seek isn't important, only Read Extended and Write Extended
(minor nit).

	Like I said, the real problem is the current FS accesses the driver by
byte offset, not block.  This limits usable disk space to 4gig until we need
to revise the driver and/or FS.

>	Boy! It's a good thing partition BAM storage is in fast ram! :-)

	With 2.0 FS, it isn't (or you'd need VM just to hold them... :-) :-)

-- 
Randell Jesup, Keeper of AmigaDos, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com  BIX: rjesup  
Common phrase heard at Amiga Devcon '89: "It's in there!"