Path: utzoo!attcan!uunet!cbmvax!steveb
From: steveb@cbmvax.UUCP (Steve Beats)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Giant disks
Message-ID: <4932@cbmvax.UUCP>
Date: 3 Oct 88 22:01:22 GMT
References: <4912@cbmvax.UUCP> <176@antares.UUCP>
Reply-To: steveb@cbmvax.UUCP (Steve Beats)
Organization: Commodore Technology, West Chester, PA
Lines: 26

In article <176@antares.UUCP> jms@antares.UUCP (joe smith) writes:
>
>OK, I'll bite.  Why can't the filing system use logical blocks?  Regardless
>of the current data structures that the harddisk.device uses, why can't it
>add a cylinder (or block) offset after converting the request byte offset
>into block # and offset with block?
>
Internally, the filing system DOES use logical blocks.  Right now they're
hard coded at 512 bytes which allows the FS to access about 4 Terabytes of
media.  Under the 1.4 filing system, true variable block size will be
implemented (I wonder how I knew that :-) so this limit can be raised
appreciably by going to 1K or 2K block sizes.  The problem arises when
the filing system has to talk to an exec device.  The IO_OFFSET field of
an IORequest is 32 bits of BYTE offset, not BLOCK offset.  This limits 
the range to 2^32 or about 4.5 Gigabytes.

The obvious answer is to write a device driver that takes a block number
in the IO_OFFSET field but this would be incompatible.  I don't see any
backwards compatible way for the FS to know whether it has to request
block offsets or byte offsets.  Well, actually I do see a way.  A new
device command class could be added that expects offsets in blocks as
opposed to bytes.  The filing system could check if this command was 
accepted at initialisation time and adjust accordingly.  Question is:
what numbers do the new commands take and is this an acceptable solution ?

	Steve