Hello all,
It took a while to solve this ... my thanks to everyone who
originally responded. The ideas were very helpful.
Original problem: Try to ufsdump a 20+gig disk to an 8mm, 160m
tape. The ufsdump would error out at what appeared to be the end of the
first tape, despite using the "l" option in the ufsdump command.
Solution: When the 20+gig partition was split in to two 10-gig
partitions, the ufsdump worked! We were also able to ufsdump a 13-gig
partition to multiple 8 mm tapes without using compression.
My guess, which I have presented to Sun Support, is that we have hit
some kind of hard-coded limit with ufsdump with 20+gig partitions. Perhaps
the fact that the 20+gig partition is larger than the capacity of a single
8mm tape (14+ gig using compression) has something to do with it, even
though the "l" option is used.
Would anyone out there have any ideas or opinions on why a partition
that large wouldn't work?
Is anyone out there using a Seagate Barracuda disk (18 gig) as a
single partition and using ufsdump? After formatting the Barracuda, how
large is the partition?
> -----Original Message-----
> From: Avrami, Louis [SMTP:L.Avrami@dialogic.com]
> Sent: Wednesday, June 10, 1998 11:39 PM
> To: Sun Managers List
> Subject: ufsdump problem
> Importance: High
>
> Hello all,
>
> I'm having a problem trying to ufsdump a filesystem.
>
> Platform is an Enterprise 4000, Solaris 2.5.1. The tape
> dirve I'm trying to dump to is a SPARCstorage 8/140 tape library with an
> Exabyte 8505C drive. The filesystem that I'm trying to dump is on a
> Seagate
> 23.2 GB Elite (ST423451) disk, one filesystem approximately 20 gig.
>
> > I've just been trying to ufsdump the disk interactively so far:
> >
> > nohup /usr/sbin/ufsdump 0ucfl /dev/rmt/1hbn /dev/rdsk/c4t1d0s3 &
> >
> > Here is what the output looks like:
> >
> > DUMP: Writing 63 Kilobyte records
> > DUMP: Date of this level 0 dump: Wed Jun 10 16:19:48 1998
> > DUMP: Date of last level 0 dump: the epoch
> > DUMP: Dumping /dev/rdsk/c4t1d0s3 (itsun2:/disk231) to /dev/rmt/1hbn.
> > DUMP: Mapping (Pass I) [regular files]
> > DUMP: Mapping (Pass II) [directories]
> > DUMP: Estimated 38436998 blocks (18768.07MB).
> > DUMP: Dumping (Pass III) [directories]
> > DUMP: Dumping (Pass IV) [regular files]
> > DUMP: 6.06% done, finished in 2:35
> > DUMP: Write error 21522 feet into tape 1
> > DUMP: NEEDS ATTENTION: Do you want to restart?: ("yes" or "no")
> >
> >
> > This takes about 20 minutes to run, since /disk231 has approximately
> > 20 gig of data on it. It looks like the first tape fills up, and it
> > cannot advance to the next tape.
> >
> The capacity of the 8mm tapes is approximately 16 gig when
> writing to the drive with the 'hb' options, so we need this dump to span
> tapes. We do this at night, so we also need it to run unattended.
>
> We're using the 'l' option, autoload, with ufsdump ... the
> tape library is set up in sequential mode .... if anyone has any
> suggestions
> for debugging this, please let me know. I will summarize.
>
> Thanks,
>
> > Lou Avrami
> >
> > Get the Dialogic Edge at http://www.dialogic.com
> >
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:12:43 CDT