Re: ufsdump/restore size limit?

In article <dnprp3$jj$1@xxxxxxxxxxxxxxxxxxxxxxxxxx> Jeff Wieland <wieland@xxxxxxxxxxxxxxxx> writes:
>In article <vilain-2A246E.01510214122005@xxxxxxxxxxxxxxxxxxxxxxxx> Michael Vilain <vilain@xxxxxxxxxxx> writes:
>>In article <dno9c6$6f2$1@xxxxxxxxxxxxxxxxxxxxxxxxxx>,
>> Jeff Wieland <wieland@xxxxxxxxxxxxxxxx> wrote:
>>
>>> I'm having a problem restoring a fairly large file system under Solaris 8.
>>> The hardware is a Sun Fire V240, with a third-party SCSI-to-SCSI raid
>>> controller. The filesystem is just shy of 300 GB, with about 100 GB in
>>> use. We're using ufs, and ufsdump and ufsrestore, dumping to an SDLT
>>> drive that's directly attached to the V240. We are current with Solaris
>>> 8 patches.
>>>
>>> We periodically restore the dumps to an old machine that we use for
>>> testing, just to make sure that they can be restored. I can no longer
>>> restore the dumps -- ufsrestore asks for a second tape, when there isn't
>>> one. Even if we dump to a file on another server, and then try to
>>> restore from that, ufsdump still asks for a second tape/file to restore
>>> from. The dump files don't appear to be truncated.
>>>
>>> Are there any limits to what ufsdump & restore can handle? I sure
>>> can't find anything about this.
>>> --
>>> Jeff Wieland
>>
>>I recall ufsrestore always asking for a 2nd tape and just replying no or
>>0 or something like that. It's been a couple years. Isn't this
>>standard behavior for a full ufsrestore? It doesn't keep any volume
>>info on the tape and you have to tell ufsrestore it's done.
>>
>>--
>>DeeDee, don't press that button! DeeDee! NO! Dee...
>
>Hmmm. It doesn't ask for a second tape for other dumps, like /opt or
>root.
>--
>Jeff Wieland

On the odd chance that there was a filesystem consistency problem, we
rebooted the system single user and ran an fsck on it -- no problems
were found.

There appears to be nothing that I can type at the "Specify next volume #:"
prompt to get ufsrestore to complete. I've tried n, no, and q to no avail.
--
Jeff Wieland
.