Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!ukma!nrl-cmf!ames!pasteur!ucbvax!CORY.BERKELEY.EDU!dillon
From: dillon@CORY.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Giant disks
Message-ID: <8810121739.AA15082@cory.Berkeley.EDU>
Date: 12 Oct 88 17:39:29 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 32

:>A 4096 byte block size would let you have 8 times the amount of storage
:>the current 512 byte block size would before overflowing...
:
Bob Page, U of Lowell CS Dept.  page@swan.ulowell.edu  ulowell!page Writes:
:bits in another place.  If you just decreed that the offset was in
:terms of 'blocks' (which is driver/unit/partition dependent), you'd
:break all existing I/O requests.
:
:...Bob

	There is another problem.  If we add a new command or flag
bit to the trackdisk device saying 'offset is in blocks' instead of bytes,
if anybody ever *does* put in a disk that big you couldn't use the old
method anyway and all existing programs that go directly to the trackdisk
will break.

	The best thing to do is to have CMD_READ/WRITE fail with the
new drivers and add new CMD_? calls to the trackdisk for read/write ops
that takes blocks instead of bytes.  Or BETTER, if the device is too
large have CMD_READ/WRITE fail, else allow them to work.  The main point
is to NOT allow application programs access via the old calls if the disk is 
too big.... better to have them fail, no?  

	I like that second idea ... after all, what will fail on the super
large disks?  The system software won't because it will have been changed
to use the new calls exclusively.  Games might but it isn't a problem if you 
run them off other storage.  About the only thing that WILL fail are 
third-party/shareware/freeware packages that access that particular 
trackdisk.device ... not many, and not a major problem because only the
super-large storage device is affected.

				-Matt