Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!uhccux!munnari.oz.au!olympic!enno
From: enno@olympic.oz (Enno Davids)
Newsgroups: comp.sys.amiga.tech
Subject: Re: help with disk/tape device driver(s)
Summary: Tape device handlers/filesystems
Keywords: device drivers, SCSI
Message-ID: <1072@olympic.oz>
Date: 26 Jul 89 08:19:42 GMT
References: <1006@olympic.oz> <5107@tekigm2.MEN.TEK.COM> <1048@olympic.oz> <4172@amiga.UUCP>
Organization: Olympic Amusements, Melbourne, Australia.
Lines: 65

In article <4172@amiga.UUCP>, kodiak@amiga.UUCP (Robert R. Burns) writes:
> In articles ... Michael van Elst and Enno Davids write about SCSI disk and
> tape support at the exec device level.  A (standard or fast) DOS file
> system is associated with a SCSI disk thru an exec device (e.g. hddisk.device)
> that looks like the trackdisk.device.  There is no corresponding DOS handler
> for tape drives at present.  A backup program that I know of that uses SCSI

As I have been playing with this perhaps you would like some observations.

The DC2000 based QIC100 tape drives I have been playing with all support 
random I/O (i.e they can read/write at arbitrary points on the tape) and
could conceivably be used with current filesystems and handlers. Trying this
would fairly quickly become tiresome due to the excessive amounts of time
winding tape from end to end can take. So, to enhance a current filesystem
to work here is a minimal list of what needs to be done. (BTW, I don't claim
this list is exhaustive, merely that it hits some of the high points):

    - An analog of MaxTransfer (MinTransfer?) for mountlist to allow the
	handler to work optimally with non 512 byte blocked devices. Handlers
	might still be required to pre-read a block to perform a shorter write
	operation(?).
    - Caching of directories in the handler and possibly use of a fixed size
	(pre-allocated?) directory kept at the start of tape. This more like
	the inode area of the old **IX disk organisation than current Amiga
	filesystems.
    - Some way of telling the handler about the cost of seeking from one 
	(tape) block to the next so that it can attempt to optimise this.


> tapes (BRU) does so via SCSI commands issued directly thru the tape drive
> thru the same exec device using the HD_SCSICMD command described in the
> 1.3 include file <devices/scsidisk.h>.  We encourage all applications requiring
> access to something other than a magnetic disk on SCSI to use this command,
> and all writers of SCSI exec-level drivers to support it.

This isn't hard to provide, but I find the choice of HD_SCSICMD (it's value)
to be a little kludgy. (What if you already have more commands than this? If
you don't you probably fill the command table with a bunch of dummy entries
because you have too few.) 

My solution was to have a completely separate task doing the SCSI bus
management. Any device driver could still offer HD_SCSICMD by simply accepting
such commands and then passing them on to the SCSI task. This also means that
the SCSI access is no longer reliant on some particular device being mounted
(e.g tape restore to an unmounted hard drive, etc.). Just some thoughts.

Finally, a repeat question. Is there any other documentation that pertains to
the information in scsidisk.h/hardblocks.h other than the includes themselves?


Nice to talk to you,

Enno.


-------
Enno Davids					Voice:	+61 3 562 4255
Olympic Video Gaming P/L.			Fax:	+61 3 562 4889
1562-68 Centre Rd.
Springvale, 3171				ACSnet:	enno@olympic.oz
Australia

"... and in the event of your capture the secretary will disavow any knowledge
of your actions or agreement with your opinions. This netnews item will self-
			destruct in five seconds."