Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!hplabs!otter.hpl.hp.com!hpltoad!hpopd!hpcpbla!stevej From: stevej@hpcpbla.HP.COM (Steve Jerman) Newsgroups: comp.periphs.scsi Subject: Re: Random Access DAT Message-ID: <9850031@hpcpbla.HP.COM> Date: 18 Jun 91 08:51:20 GMT References: <1991Jun14.211246.4340@newshost.anu.edu.au> Organization: HP Computer Peripherals Bristol, UK Lines: 133 Hi Albert, I'll try and answer some of these applications questions as I'm more involved with the applications side than Kev. Bare in mind that my knowledge is HP focused. >I take it that, and the detail I have omitted about how it works, means >the answer to my Q2 is "Yes" i.e. a Unix device driver normally used >just for backup streaming can be expected to properly implement >commands to seek to any given location. One would not expect such a driver >to be implemented like a tty or lineprinter that doesn't know what "seek" >means (even though that would be sufficient for backup streaming). Please >confirm. Yes, most U**x sequential tape drivers have a 'mt' command and ioctl control for the drive. This means that space commands can be used from applications. Almost all the Unix systems I have knowledge of have this sort of capability although some systems implement it in different ways. >I take it, from the lack of any other answer to my Q1, that you are >unaware of any software that uses the DDS facilities available, >although you are familiar with the technical details of what can >be done. This seems strange. What's the point of providing this stuff >if nobody uses it? This also relates to Q7 - you seem to know your >stuff and work for HP on DDS DAT - why don't they produce some >sample random access software instead of just selling it as a >backup streamer? There are third party solutions for HP and other kit that provide fast file recovery facilities. As far as HP products are concerned. The following is available (not we are working on more than this): o Fbackup (supplied with HPUX) supports f.f.r from HP-UX 8.0 o Omniback (separate network backup product) on Domain and very soon on HP-UX. This is not an exhaustive list, just the main workstation products. Also see appended utility, should work on most U**x systems and makes small archives easily accessible. >I take it from this, and the reference to mt in your answer to my Q1 >and Q2, that your answer to my Q4 is "Yes". i.e. that one could >put literally thousands of files separated by filemarks on tape >in the normal way using successive outputs to a non-rewind device >driver and just use "mt" for skipping to the appropriate file for >retrieval and still get the full benefits of fast tape movement >without having to use any "seek" commands at block level. This >implies that the application described in Q3 may as well use >that simple filemark method (Q4) and there is no point bothering >about seeks to specific block numbers for it. Please confirm. Yup - see end of message. >The way I understand it, cpio and tar just write to stdout. When the >cpio or tar process finishes and closes stdout it is not cpio or tar but >the device driver that causes a rewind unless it is a non-rewind device driver >- usually both are available (using a 1 bit difference in minor >device numbers). Thus storing a series of cpio or tar files separated >by filemarks should be absolutely no different in principle from just >storing any other files (e.g. using cat or cp). >What I meant was using a SINGLE tape file produced by cpio or tar to >hold thousands of individual files and EITHER recover individual files >or sets of them using cpio or tar (which implies slowly reading through >the whole tape file), OR seek directly to the tape blocks that hold >the individual file required. The latter alternative would require >building some sort of index to the cpio or tar file as it is being >produced. Seems to me that since you say there is no performance >penalty for using filemarks I may as well just use the "mt" approach. see end again. >I take it the distinction between "stacker" and "juke box" is that >with a "stacker" you cannot randomly select the next cassette but >only get them one after the other in the order they were stacked >(and you would have to reload manually after getting to number 12). >Please confirm. correct - also implies cheaper and simpler. >If so, that would still be very useful for some computer purposes, >though less useful than a fully random access juke box. It could >even be used for the file archive application responding to mail >requests that I mentioned in Q3 (as well as for ordinary very >large backups etc.) There would just be a batch cycle proceeding >through all 12 tapes to fill any mail requests (though having >to restack after each batch is unfortunate, it could be done >only once or twice per day). Can you please provide any details >you have available on who is marketing "stackers" and >at what price? Also, are they audio or computer devices and if audio, >would there be any difficulty using the stacker mechanism with a >computer DAT drive? Sorry I don't have that information. >I don't understand this answer. My understanding was that the audio DAT >format is fully digital and the DDS format is just a particular form of >it that defines block numbers etc. If so, why should only the mechanism >be the same and not also the digital electronics (including read/write >amplifiers)? If there is a digital signal being recorded and played >back, why should accessing that for audio be any more difficult than >recording an audio CD (digitally) on a DAT? I can understand there >might be extra stuff for fast searches etc but surely more than the >mechanism is the same. The DDS format is an extra logical layer on top of the audio format. (like OSI layers). The mechanism could be the same between Audio and digital data but complication would be added to separate of the audio and digital data and also to route that data to a speaker jack - no impossible though. >I just saw a note about SCSI DATs available for USD $1500, c.f. >$2500 when the one I'm using was bought. I guess the current >prices are closer to reflecting the design costs you describe. Price erosion is a wonderful thing ... Hope this helps Steve Jerman Hewlett Packard Computer Peripherals Bristol Address: Email: Filton Road stevej@hpcpbla.bri.hp.com Stoke Gifford Bristol BS12 6QZ UK Phone: Fax: (44) 272 799910 x22424 (44) 272 236194 This response does not represent the official position of, or statement by, the Hewlett-Packard Company. The above data is provided for informational purposes only. It is supplied without warranty of any kind.