Path: utzoo!attcan!uunet!cbmvax!ulowell!page
From: page@swan.ulowell.edu (Bob Page)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Giant disks
Message-ID: <9456@swan.ulowell.edu>
Date: 4 Oct 88 14:51:05 GMT
References: <4912@cbmvax.UUCP> <176@antares.UUCP> <4932@cbmvax.UUCP>
Reply-To: page@swan.ulowell.edu (Bob Page)
Organization: University of Lowell, Computer Science Dept.
Lines: 57

steveb@cbmvax.UUCP (Steve Beats) wrote:
>Under the 1.4 filing system, true variable block size will be implemented

Hooray!  Next we'll have cylinder groups, file links and an AREXX port :-)

>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.

Here's the current IOStdReq block:

struct IOStdReq {
    struct  Message io_Message;
    struct  Device  *io_Device;     /* device node pointer  */
    struct  Unit    *io_Unit;       /* unit (driver private)*/
    UWORD   io_Command;             /* device command */
    UBYTE   io_Flags;
    BYTE    io_Error;               /* error or warning num */
    ULONG   io_Actual;              /* actual number of bytes transferred */
    ULONG   io_Length;              /* requested number bytes transferred*/
    APTR    io_Data;                /* points to data area */
    ULONG   io_Offset;              /* offset for block structured devices */
};

Why not have the application PASS IN a magic cookie to io_Error, or
io_Flags (or somewhere obtuse like io_Message.mn_ReplyPort->mp_Flags).	:-)
The device then knows "OK, the value in io_Offset is in
BLOCKS, not BYTES."  If the magic cookie isn't there, we just treat
it as a byte offset, like always.

>I don't see any backwards compatible way for the FS to know whether
>it has to request block offsets or byte offsets.

It doesn't have to know.  Dump theory and go with what's practical.
Have the file system use the old method to access any data under
4.5GB.  If you have to go over 4.5GB, only the devices that know about
BLOCK offsets will be able to do it, and since you haven't defined how
to do that, nobody has devices that can, and nobody will until you
define how to do it.  By the time 1.4 is in developer's hands, they'll
all have known about the BLOCK offset for a long time.  Nobody's going
to get burned.

>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 ?

I think this is too much work.  You're trying to be compatible with
something that doesn't exist, and may actually be less compatible with
existing stuff, since you might be sending currently private commands
to the driver.

..Bob
-- 
Bob Page, U of Lowell CS Dept.  page@swan.ulowell.edu  ulowell!page