reading%uinta.utah.edu@cs.utah.edu (Dan L. Reading) (10/21/90)
Any DAT experts out there? I've written a SCSI tape driver that handles several different tape drives (including Exabyte) I'm now working on a DAT drive. Let's say you have a tape with some files: ------file1------|FMK1|--file2--|FMK2|----file3----|FMK3| Now rewind the tape and write a short file on top of file1, do not write a FMK. We should have something like this: -file4-[garbage]--|FMK1|--file2--|FMK2|----file3----|FMK3| So you should be able to read file4, fsf, read file2, read file3. With the DAT drive it appears to make a erase zone has it writes file4 which can not be spaced past. ie. read file4, fsf BLANK CHECK, fsf BLANK CHECK, etc. Is this what's happening? Is there anyway to get past the erase zone? Thanks for any tips, Dan --------- reading@cs.utah.edu reading@cs.utah.edu
kev@hpcpbla.HP.COM (Kevin Jones) (10/23/90)
Assuming the DAT Drive writes DDS format tapes (HP, SONY, Archive, WangTEC, WangDAT ...) You are correct in assuming the drive puts down an erase zone at end of data. In fact, it writes a specific "End Of Data" pattern which it can detect on subsequent passes (even at x200 speed). This will be approx 10 seconds worth of tape at x1 speed. The DDS format specifies that anything on tape FOLLOWING an end of data pattern, within the current partition, is UNDEFINED. In short, DDS does not allow "tricks" involving the recovery of beyond EOD data. The main reason for this is that there is no direct correlation between DATA SIZE and the LENGTH of tape required to hold that data. Numerous variables (Rewrites of bad frames, writing of Amble frames, Writing of partially full groups, and various other format features) act against the would-be "Update in place" mechanic. eg. You write the follwing....... > ------file1------|FMK1|--file2--|FMK2|----file3----|FMK3| Where file1 is just a space holder (say 10 MBytes) > Now rewind the tape and write a short file on top of file1, do not > write a FMK. We should have something like this: > -file4-[garbage]--|FMK1|--file2--|FMK2|----file3----|FMK3| > So you should be able to read file4, fsf, read file2, read file3. Even if file4 is only 5MBytes, you could well find the final tape looks more like: -file4-------------------[garbage]-|FMK2|----file3----|FMK3| Any DAT drive correctly implementing the DDS format should prevent you from trying to read beyond EOD. MEDIUM PARTITIONS ----------------------------- > Is there anyway to get past the erase zone? NO. If what you're trying to do is some sort of update in place (eg. to store directory info at the start of tape), then medium partitions are the "official" way of doing this...... The DDS format supports the ability to create either a 1 or a 2 paritition tape. A 1 partition tape is a "normal" tape....... |-------------------------------------|-----------| BOP0 EOD EOP0 Where BOP =Beginning of partition, EOP=End Of Partition. A 2 partition tape looks like: |-------------|------||---------------|-----------| BOP1 EOD EOP1 BOP0 EOD EOP0. ie. 2 LOGICAL tapes on 1 PHYSICAL tape. Note I have numbered partitions as partition 0 and partition 1. DDS places partition 1 at the physical start of medium, and partition 0 following. With the appropriate SCSI commands, it is possible to do the following on a DDS DAT drive: 1. Format a tape to contain 2 partitions, specifying the amount of data partition 1 must be able to hold. (This is done on an HP drive by sending a MODE SELECT medium paritions page). I am not sure how other vendors implement this. 2. Change partitions. ie. switch to partition X (X = 0 or 1). HP drives can be told to go to a partition by sending a MODE SELECT DEVICE CONFIGURATION page (with the appropriate fields set). I am not sure how other vendors implement this. (Note: It may also be possible to change partitions using a SCSI LOCATE command). Once "inside" a partition, the drive will act as though that partition is a logical tape. All reads/writes occur within that partition. END OF PARITION/MEDIUM will be reported if you try to overfill it. The drive will not permit the contents of one partition to "overflow" into the following partition. HP DDS drives implement MEDIUM PARTITIONS, both at DDS format level, and in terms of the SCSI commands/pages required to support this feature. I don't know how well partitions are implemented on other DAT drives. Regards, Kevin. ----------------------------------------------------------------- Kevin Jones. | Hewlett Packard Ltd, | Computer Peripherals Bristol, kev%hpcpbla@hplb.hpl.hp.com | Filton Road, | Stoke Gifford, Tel: 011 44 272 799910 (ext 22351) | Bristol. BS12 6QZ. | ENGLAND. ----------------------------------------------------------------- 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.
danderson@allvax.enet.dec.com (Dave Anderson) (10/24/90)
In article <9850001@hpcpbla.HP.COM>, kev@hpcpbla.HP.COM (Kevin Jones) writes... >Assuming the DAT Drive writes DDS format tapes (HP, SONY, Archive, >WangTEC, WangDAT ...) > >You are correct in assuming the drive puts down an erase zone at >end of data. > >In fact, it writes a specific "End Of Data" pattern which it can >detect on subsequent passes (even at x200 speed). > >... > >The DDS format specifies that anything on tape FOLLOWING an end of >data pattern, within the current partition, is UNDEFINED. > >In short, DDS does not allow "tricks" involving the recovery of >beyond EOD data. ... So DAT/DDS was deliberately designed to make it totally impossible to ever read any data beyond EOD? Is one supposed to cheerfully write off the gigabyte of vital data that's still on a backup tape that someone accidentally wrote over the beginning of? While I understand (and agree with) the premise that 'rewrite in place' is unreliable and should not be attempted, there are certainly cases where the ability to read whatever data remains on a partially written-over tape can be vitally important! It sounds like a very bad idea to use this format for backups. Dave [The above is my opinion only -- I don't know of anyone else who'd want it.]