Hello managers,
I wrote that I dumped a file system to the default tape device but the
device where the "restore -t" command found the dumped system occured
/dev/rmt1h instead of /dev/rmt0h as I expected. Apart from that, I wondered
why in the /dev directory there were two devices although there is the only
tape drive in the system.
Many thanks to
alan_at_nabeth.cxo.dec.com
Dr. Tom Blinn tpb_at_doctor.zk3.dec.com
Bryan.Lavelle_at_COMPAQ.com
Felix Maurer maurerf_at_post.ch
As always [well, almost always :-) ], no mystery. I confused the system
myself having created the tape device with MAKEDEV tz0 instead of MAKEDEV tz3
whereas in the configuration it is tz3. The cause was confusing SCSI logical
unit and tape logical device numbers. Moreover, it seems that I did it
(inadvertently) twice, as I can judge now according to the times upon
ls -l /dev/*rmt* - for unused files (for other BPI, because for the devices
really used in dumping, the times were changed during calling them), the
difference between the times when devices "0" and "1" were created is 5 mins.
Alan recommends (carefully) removing all the rmt and nrmt devices and then
using MAKEDEV to create the rmt0 devices for tz3.
Besides, Tom Blinn says, 'I can not promise you that restore uses the same
name for the file it tries to read as what dump uses, but if it does, it
might try to do some kind of tape operation on the file as part of the
"-t" operation, and if it's not really a tape, it may not work. I don't know
if that was a part of what happened -- it could be'.
Two whole replies with additional useful information are included beneath,
together with my original posting.
Thanks again,
Irene
*************************************************************************
* *
* Irene A. Shilikhina e-mail: irene_at_alpha.iae.nsk.su *
* System administrator, *
* Institute of Automation & Electrometry, *
* Siberian Branch of Russian Academy of Sciences, *
* Novosibirsk, Russia *
*
http://www.iae.nsk.su/~irene *
*************************************************************************
* *
* The road to hell is paved with good intentions. *
* *
* [...has proved to be as actual at the end of XX as ages before...] *
* *
*************************************************************************
From alan_at_nabeth.cxo.dec.com
Date: Fri, 10 Sep 99 11:24:19 -0600
From: alan_at_nabeth.cxo.dec.com
To: "Irene A. Shilikhina" <irene_at_alpha.iae.nsk.su>
Subject: Re: Misterious changing /dev/rmt?h number during dumping
The rmt devices are created in sequential order according to
the order of the MAKEDEV commands. V4.0 will also create
special files for devices that don't exist when the system
boots. Those will probably get created in the order that
the system finds the devices.
If you used tz0 with the MAKEDEV command, when the device
was really tz3, then rmt0 doesn't have a tape associated
with it (thought it might be a disk, which could cause
all manner of problems or interesting failures). The tz3
devices would have been created for you at the last reboot
after the tape was added.
SCSI tape physical numbering based on the bus, target and
logical unit number. MAKEDEV can only create devices for
LUN 0 devices, using the formula:
tz#, where # = (bus * 8) + target-id
In the case of tz3, this would be bus 0, target 3. Scsimgr
can create non-LUN 0 devices. I would recommend (carefully)
removing all the rmt and nrmt devices and then using MAKEDEV
to create the rmt0 devices for tz3.
*************************************************************************
From tpb_at_doctor.zk3.dec.com
Date: Fri, 10 Sep 1999 12:18:39 -0400
From: "Dr. Tom Blinn, 603-884-0646" <tpb_at_doctor.zk3.dec.com>
To: "Irene A. Shilikhina" <irene_at_alpha.iae.nsk.su>
Subject: Re: Misterious changing /dev/rmt?h number during dumping
If your tape drive is really SCSI logical unit 3 on bus 0 (tz3), then when
you create the tape logical devices (rmt and nrmt) using MAKEDEV, you MUST
reference tz3, not tz0 (as you report you did, incorrectly).
If you have created the /dev/rmt0? and /dev/nrmt0? device names, and then
you go into /dev and do ./MAKEDEV tz3 (where that was already done before),
the MAKEDEV script will create rmt1 devices that point to tz3, just as the
rmt0 devices may do (and the related "n" device names). In other words, you
can mess yourself up by doing this.
If there is no device file name for the default device "dump" uses, and you
do a dump without specifying a device explicitly, then dump with create a
normal file with the appropriate name in the /dev directory (which is in the
root file system normally) and write the dump into that file (which I think
will be "rmt0a" unless its "rmt0h") instead of to a tape device.
In other words, you can mess yourself up because it's UNIX and you seem to
have set up your system incorrectly if you really did the things you say you
did. By the way, I can not promise you that restore uses the same name for
the file it tries to read as what dump uses, but if it does, it might try to
do some kind of tape operation on the file as part of the "-t" operation,
and if it's not really a tape, it may not work. I don't know if that was
a part of what happened -- it could be.
In other words, what you wrote sounds like a classic "user error" story to
me.
Tom
*************************************************************************
ORIGINAL POSTING
----------------
On Fri, 10 Sep 1999, Irene A. Shilikhina wrote:
>
> Hello managers,
>
> After having successfuly completed the file system dumping to, I THOUGHT,
> /dev/rmt0h, according to the default:
>
> # dump -0u /usr
>
> I wanted - as usual - to be sure everything was OK:
>
> # restore -t
>
> but nothing happened, the tape device was silent and the command hung.
> <Ctrl>C did'n work out either. One or two minutes later (doing nothing is
> sometimes not so bad thing...) the message about interrupting appeared,
> and fortunately I was able to exit from the command.
>
> Already being sure I could escape from the command causing the problem,
> due to some timeout [patience is often rewarded :-) ], I started trying the
> command with various arguments, and - to my great surprise - I found out that
> by that time the tape device (we have the only one!) had become /dev/rmt1h
> (!?!), because the following command succeeded:
>
> # restore -t /dev/rmt1h
>
> After dumping another file system I expected the same but this time
> everything was as it must be.
>
> It was when I pondered over WHY the system had created the devices with
> two numbers (0 and 1) in the /dev directory upon ./MAKEDEV tz0 . I noticed
> it earlier when installing the tape drive but then I didn't concern about
> it. Is it logical numbers - and then what for if there is a single
> physical one? From the system configuration:
>
> alpha vmunix: tz3 at scsi0 target 3 lun 0 (LID=3) (WANGTEK 5525ES SCSI
> REV7 3J2 )
>
> Some observations that might be relevant:
>
> the dump in question put out the estimation information that was erroneus -
> ~480,000 tape blocks in 2 volume(s), although the tape was 525M, and actually
> everything fitted to 1 volume, there were messages about dumping succeded.
> But as far as I know, the estimation information is not of much importance,
> so I didn't attach much attention to it. The second dump was for the / file
> system, and therefore was very small and fitted into 1 volume.
>
> Is it any relation between multivolume support and the number of logical
> devices?
>
> The system is DEC 2000 model 300 with DU4.0D running successfuly for a few
> mounths (installed from scratch, without any pathches yet - do we need any?).
>
> Thanks,
> Irene
*************************************************************************
Received on Mon Sep 13 1999 - 07:51:20 NZST