Date: Sun, 12 Aug 2001 11:46:57 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Bernd Walter <ticso@mail.cicely.de> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: mtio questions Message-ID: <3B76CF21.C6915AB0@mindspring.com> References: <20010812140406.A7326@cicely20.cicely.de>
next in thread | previous in thread | raw e-mail | index | archive | help
I'm sure others will pitch in with their own folklore on this; I personally have a long history with tape drive wrangling, on about 140 different brands of UNIX, with all sorts of different drives, drivers, and firmware, so I will give you what I know... Bernd Walter wrote: > > Asume the following code examples: [ ... simple close ... ] [ ... write, write filemark and close ... ] [ ... write, write filemark, rewind, close ... ] > The question is what filemark layout will I have on the tape? It depends on what the tape drive requires for synchronization, since some tape drives require marks, and some do not. It also depends on whether there is state tracking in the particular driver, such that a rewind operation resets the "write EOF on close" for drives which require an EOF in all cases... so your last case is extremely ambiguous, unless you have a DEC-like tapedrive, which allows record addressing, and the driver recognizes this fact (DEC tape drives are random access block devices). Life is further complicated by FreeBSD's removal of block devices; it's now impossible to correctly write a tape that has non-"conv=sync" type semantics, like Sun 3, Arrete, NCR Tower, NCR Tower XP, and NCR Tower 32 systems. Much of the early UNIX industry cribbed a lot of code from NCR tape drivers and firmware. But not all of them. The Computone, Archive, and other QIC tape controllers for SCO Xenix, and all of the SCSI drives which could be written via block device to end on odd tape block boundaries, are left out. It was very common practice to duplicate distribution tapes on SCO systems using Computone controllers, which could be jumpered for QIC-11 as well as the factory default of QIC-24 (though the jumper setting was only read by the driver on a reboot: an external toggle switch only bought you the ability to select boot time configuration, which was still better than cracking the case, or having to leave it cracked). For these tapes to be usable on many systems, you had to use the block device so you could control the block size, and then you had to use "conv=sync" for those machines that needed a full block boundary before the EOF, or they would lose the last block, AND you had to _not_ use "conv=sync" for those systems where the NULL bytes at the end of the last block would be appended to the last file in your archive (a true bugger, if the last thing were compressed). > If I MTEOD on the tape and write - will I have the same result with > all examples? No. On many devices, end of media is signalled by two EOF marks in a row, and an explicit EOF mark write will write one of these. An EOD generally writes a single EOF mark. In the "write EOF on close" case, we are really talking about "write EOD, which is indicated by a single EOF, and not two EOF's" -- the double EOF has to be done explicitly, and effectively ends the tape, if you do not overwrite it (many systems have an "mt format" to allow you to do this correctly). > May I get into trouble with some tape types that use 2 filemarks EOD > detection? Yes. > Ist the result OS dependend? It is driver and tape drive dependent; since the driver is part of the OS, the answer is "yes". The problem you face is that some OS's do the work to recognize tape drives with different requirements, and then treat them differently, with regard to the close semantics. Generally, you would set which semantics your drive requires with the "mt" command; more work, but you can always work around the OS "guessing wrong" that way. > Another point: > Can we '#define MTEOM MTEOD' as MTEOM is used on NetBSD and Solaris? "End of Message" is not the same as "End of Data" for some drives; this could break old 8-track (no, not the music, and not a typeo for "9-track"!) drives, e.g. Zilog and Cypher. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B76CF21.C6915AB0>