Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!lgc.com!mips.mitek.com!convex!mic!letni!rwsys!merch!cpe!adaptex!adaptx1!neese From: neese@adaptx1.UUCP Newsgroups: comp.periphs.scsi Subject: Re: Random Access DAT Message-ID: <283400153@adaptx1> Date: 20 Jun 91 07:37:39 GMT References: <4340@newshost.anu.edu.au> Lines: 99 Nf-ID: #R:newshost.anu.edu.au:4340:adaptx1:283400153:000:4995 Nf-From: adaptx1.UUCP!neese Jun 19 17:52:00 1991 >> BEWARE! The method youare refering to is called QFA (Quick File Access) >> and is implemented very differently from manufacturer to manufacturer. This >> was due to the lack of a defination in the SCSI spec when these devices >> were designed. The spec now contains the new commands for this, but it will >> be a while before everyone implments them. > >There are no problems with DDS "Random Access". > * Not with the tape format > * Not with the search algorithms > * Not with the SCSI interface spec > * Not with any host driver that has correctly implemented the > SCSI "Space" command. > >There are now 3 methods of achieving "Random Access" via SCSI commands >that I'm aware of: > >1. Using the SCSI "SPACE" command. This can instruct the drive to > space FILEMARKS, SETMARKS, RECORDS and Sequential Filemarks/Setmarks > (a "sequential" mark is a group of marks, eg. "Space 2 sequential > Filemarks" = Space to the next pair of filemarks). > All spacing is done relative to the current tape position. > This is the command which would be used in response to an 'mt' on > UNIX. Most host drivers implement it. Its trivial. There is no > ambiguity or misunderstandings in the SCSI spec about this command. > > DDS will "fast search" in response to a SPACE. > 8mm products will NOT since they cannot space to a "logical position". Even this has caveates. As long as you stick to using blocks or filemarks as the refernce to space by, you will be okay. Not all tape drives support seqiential filemarks, end-of-data, setmarks, or sequential setmarks. These are optional in the SCSI-2 spec and support will vary from vendor to vendor. >2. Using the SCSI "READ POSITION" and "LOCATE" commands. > I think these may be the commands Roy was warning you about. > A "Read Position" causes the drive to return the "current tape > address". You can subsequently send this address back to the > drive to get it to position to the point where you issued the > LOCATE. This seems popular with PC's where a backup application > can do a "LOCATE" before writing a file. It can then create > a tape index containing filenames and "Locate positions". > > There are some problems with using LOCATE/READ-POSITION: > 1. Many drivers don't implement these commands. > This is no big deal for DDS/UNIX since its better to use > "SPACE" anyhow. > 2. Until recently, the "current tape address" was a bit vendor > specific. ie. you could be positioned before file "x" and > LOCATE shows you are at tape address 1234, whereas in a > different manufacturers drive, at the same tape position, > LOCATE returns tape address 1235. Not all that important if > you stick with the same drive. If however you do a LOCATE > on one then feed that address into a READ POSITION on another > then you end up in the wrong place. > > This problem has now been addressed by the ANSI comittee. > Prior to that, a common understanding had developed amongst > DDS manufacturers about the definition of "current tape address" > such that interchange problems between different vendors will > not be a problem. > > 8mm products cannot utilise the LOCATE/READ-POSITION > commands to fast search. See below....... One thing you left out of this. This is what will kill you. The mode sense command for setting up the partitions is vendor specific. This was due to a lack of a standard format for this data. SCSI-2 set it right, but very few drives have moved to SCSI-2 yet. When they do, life will be easier. >3. The third method of "Random Access" is very much vendor specific. > My information on this "Random Access" method is a bit sketchy, > but it goes something like: > > A vendor unique SCSI command allows you to read the current > "track address" from the drive. A second vendor unique SCSI command > causes the drive to position to a specified track address. > > This all sounds like the LOCATE and READ POSITION commands. > The main difference is that the address returned is the physical > tape address. With LOCATE/READ-POSITION, logical addressing > means that "incrementing by 1" causes you to move up 1 block > or 1 mark (it could be argued that "READ-POSITION" is now redundant > since block addressing was standardised, and that a smart enough > driver could "mirror" what the drive would return in response > to a READ-POSITION command), with these vendor unique commands, > there is no such correlation. > > Since these commands are only a couple of months old, I would > expect to see them supported only on drivers that have been written > for 8mm products. They are not as useful as the LOCATE/READ-POSITION > commands, and NOWHERE NEAR AS USEFUL as the SPACE command. Bingo!. Roy Neese Adaptec Senior SCSI Applications Engineer UUCP @ neese@adaptex uunet!cs.utexas.edu!utacfd!merch!adaptex!neese