acheng@uiucdcsb.UUCP (04/23/87)
I think the "dd if=/dev/rmt4 of=/dev/null" works.
For the systems that I have worked with, version 7, 4.1, 4.2, 4.3,
/dev/rmt{0,8} have been raw, rewind tape
/dev/rmt{4,12} have been raw, no-rewind tape
/dev/nrmt{0,8} have been raw, no-rewind tape
All of them refer to the same tape-drive with {0,4} refer to
lower density and {8,12} the higher density. The following is
our current 4.3BSD setup (using the distributed MAKEDEV):
ls /dev/*mt*
brw-rw-rw- 1 root 5, 0 Jan 17 1986 /dev/mt0
brw-rw-rw- 1 root 5, 12 Jan 17 1986 /dev/mt12
brw-rw-rw- 1 root 5, 4 Jan 17 1986 /dev/mt4
brw-rw-rw- 1 root 5, 8 Jan 17 1986 /dev/mt8
brw-rw-rw- 1 root 5, 4 Jan 17 1986 /dev/nmt0
brw-rw-rw- 1 root 5, 12 Jan 17 1986 /dev/nmt8
crw-rw-rw- 1 root 14, 4 Jan 17 1986 /dev/nrmt0
crw-rw-rw- 1 root 14, 12 Jan 17 1986 /dev/nrmt8
crw-rw-rw- 1 root 14, 0 Apr 2 10:39 /dev/rmt0
crw-rw-rw- 1 root 14, 12 Apr 10 12:32 /dev/rmt12
crw-rw-rw- 1 root 14, 4 Apr 19 22:10 /dev/rmt4
crw-rw-rw- 1 root 14, 8 Apr 23 14:40 /dev/rmt8
The "mt fsf 1" command is simple and faster except it cannot be aborted.
If I mount a wrong tape that has no EOF tape mark or if I have skipped
forward one too many file, I will stand there helplessly, watching the
tape spin off its mount wheel. The mt will not take any signal until
the skipping is done. I have done the mistake of making the tape drive
go offline, hoping that would abort the "mt fsf 1". No luck, the process
was stuck forever waiting for the "fsf" to complete which would never come.
Worse yet, the tape device stayed open to "mt" and no other process may
open the tape device until the system is rebooted.