SUMMARY: How to Catch the EOT (End of Tape) Mark

From: SHyun.ES_XFC@xerox.com
Date: Thu Feb 18 1993 - 02:13:55 CST


I will figure out based on your inputs. Thanks everyone for the help.

Thanks to:
        fetrow@biostat.washington.edu
        eclipse!chungj@uu2.psi.com
        bert@spike.penril.com
        bzs@world.std.com
        ups!kalli!kevin@fourx.aus.sun
        apunix!susan@ucsd.edu
        
Original Question:

>
> Hello All,
>
> I am trying to write many files in tapes and these files are NOT fit in one
> tape. In the middle of writing files to tape, I got the error message ('write'
> is failed) at the end of tape (EOT). I am using SCSI tape drive on SUN OS
> 4.1.1. and my C program is using 'mtio'. I would like to know whether the
> problem is tape drive configuration or tape writing program. Might be both os
> them. If the problem is in the tape writing program, then how to catch the EOT
> mark. Is there a way to catch the EOT mark on tape in C program?

Answers:

------------------------------------------------------------
>From : bert@spike.penril

Seung,

You have, unbeknowst to you, stumbled accross the method for finding the
EOT mark on the tape. The length of tapes, no matter what form, is
dependent on many factors and you cannot determine when the EOT is. The
only way is to attempt to forward the tape, such as reading, wirting or
spacing the tape.

If you want to use multiple volumes then I would suggest that when you
encounter this error you should ask that a new tape be mounted and then
proceed with your writing to tape. If multiple volumes are not satis-
factory then you will have to expect to put a much smaller amount of
data on the tape.

BTW, the larger the "tape record" the more data that may be written
to the tape.

-- 
Bert Robbins                          Penril DataComm Networks
bert@penril.com                       1300 Quince Orchard Blvd
301/921-8600 x8856                    Gaithersburg, MD   20872

------------------------------------------------------------ From: fetrow@biostat.washington

One possible workaround for your immediate problem is compress the files on the fly onto the tape.

--

-dave fetrow- INTERNET: fetrow@biostat.washington.edu FAX: 206-543-3286 BITNET: fetrow@uwalocke ------------------------------------------------------------ From: eclipse!chungj@uu2.psi

Hi,

Only way to detect "EOT" is that whenever you have return value of 0 or short count from write() operation...

Jae Yong Chung ------------------------------------------------------------ From: bert@spike.penril

Seung,

You have, unbeknowst to you, stumbled accross the method for finding the EOT mark on the tape. The length of tapes, no matter what form, is dependent on many factors and you cannot determine when the EOT is. The only way is to attempt to forward the tape, such as reading, wirting or spacing the tape.

If you want to use multiple volumes then I would suggest that when you encounter this error you should ask that a new tape be mounted and then proceed with your writing to tape. If multiple volumes are not satis- factory then you will have to expect to put a much smaller amount of data on the tape.

BTW, the larger the "tape record" the more data that may be written to the tape.

-- Bert Robbins Penril DataComm Networks bert@penril.com 1300 Quince Orchard Blvd 301/921-8600 x8856 Gaithersburg, MD 20872

------------------------------------------------------------ From: bzs@world.std

Whether or not you can write multi-volume (multi-tape) archives is a feature (or not) of the tape utility, the OS and driver just tries to inform the application that an EOT has been reached.

So what you need is a utility which can span multiple volumes.

One that comes to mind is GNU Tar (available from prep.ai.mit.edu and other places.) It's available in source form so if you're developing your own utility you might get it just to look at how they handle EOT.

Note that dump always believes the command line parameters to calculate how many blocks fits on a tape. Unfortunately that's a very safe and conservative approach as not all devices and drivers give completely reliable EOT reporting, but you may be ok on most standard Sun devices via mtio if that's all you're worried about (rather than broad portability.)

-Barry Shein

Software Tool & Die | bzs@world.std.com | uunet!world!bzs Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD

------------------------------------------------------------ From: ups!kalli!kevin@fourx.aus.sun

Not as SunOS drivers stand - you can sense before every write, but that still won't guarantee it. Both the 472 and SCSI controllers will let you finish that write and do an EOM, as in ANSI tapes, but the Sun drivers consider it an error.

Basically, you have to note the error, have someone switch tapes, and start writing from the failed write...

l & h, kev ------------------------------------------------------------ From: apunix!susan@ucsd

Dear Seung, I believe there is a feature in our device driver "Apunix Network Backup Daemon" that will aide in this problem. This driver/backup programs combined with a EXB 10i tape handling system should correct your situation. The tape handling system is a robotic changer that holds and can handle 10 Exabyte 8 mm tapes. In combination with our driver, the EXB 10i can be set to do automatic backups of the network, using "rdump" for remote filesystems, and "mdump" for multiple filesystems. I am including as an attachment a one page description of the network software and a postscript file of our product line. If you wish to learn more about this, I would be happy to discuss it further with you and can fax you some of the man pages.

I would also welcome the opportunity to explain the discount categories listed in the pricelist.

thank you susan tornroth ------------------------------------------------------------



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:07:29 CDT