ufsdump on 170E just ... stops

ufsdump on 170E just ... stops

Post by Paul DuBo » Thu, 18 Jul 1996 04:00:00



System: Sun Ultra 1 170E with 8mm external drive
Symptom: on multi-file system dump tapes, ufsdump just stops several
file systems into the tape.  It doesn't crash, the system doesn't
hang, but the dump is doing nothing.  I can ^C to abort the dump.

Oddly enough, this *never* occurs when doing dumps from remote systems
to the Ultra.  Only when dumping its own file systems.

Is this a known problem?  Is there a patch?
--
Paul DuBois

Home page: http://www.primate.wisc.edu/people/dubois
 Software: http://www.primate.wisc.edu/software

 
 
 

ufsdump on 170E just ... stops

Post by Paul DuBo » Fri, 19 Jul 1996 04:00:00



>System: Sun Ultra 1 170E with 8mm external drive
>Symptom: on multi-file system dump tapes, ufsdump just stops several
>file systems into the tape.  It doesn't crash, the system doesn't
>hang, but the dump is doing nothing.  I can ^C to abort the dump.
>Oddly enough, this *never* occurs when doing dumps from remote systems
>to the Ultra.  Only when dumping its own file systems.
>Is this a known problem?  Is there a patch?

I got a couple of responses asking whether this was only occurring on
empty file systems, and if so, that it was a known problem.  That was
in fact the case with my machine.  The fix is to make sure something
will always be dumped.  I now execute this command in the root of the
file system before invoking ufsdump:

echo "Empty dumps fail; this file is always dumped" > $a/.dumpfix

$a is the file system root in my dump script.  Dumps now seem to
work reliably.  I haven't been able to make ufsdump hang, at least,
whereas it was quite easy before.

Thanks to Ronald Hello and Erwin Embsen for the answer I needed.

--
Paul DuBois

Home page: http://www.primate.wisc.edu/people/dubois
 Software: http://www.primate.wisc.edu/software

 
 
 

1. part 2/2 of: running ufsdump under "script ufsdump.log"

Since, to my horror, I've been having a little trouble
matching what ufsrestore finds with what I *thought* ufsdump
was writing to the tape, some *crude* verification would
reassure me:

Maybe after ufsdumping a partition, my .sh-file could have it back up
one tape-position, via:

     mt bsf 2 /dev/rmt/0cn ; mt status /dev/rmt/0cn

             [quick on-the-fly question: about that "2": is
              that very-long-standing requirement to *tell*
              "mt bsf" to back up one *more* position than
              you really want -- is that a bug, or a
              "feature" -- and if a feature, what (fiction)
              do they use to *explain* it to someone? ]

and then it would run "ufsrestore -i", and have it do just a single
"ls" before "q-uing" out of it,
...              
at which point an
      "mt status /dev/rmt/0cn"

should show that the tape had returned to the *same* position it was
when that ufsdump finished -- ie, it's in position for the
*next* ufsdump to be done.

Question: Any idea how I'd code that ufsdump *and the
ufsrestore -i" via the Bourne shell?

(Taking the time to master "expect", for this one optional
verification-use, would be overkill, at least for me.)

Thanks for everything!

David

2. help linux e solaris 8 togheter...

3. Solaris 8 ufsdump much slower than Solaris 7 ufsdump

4. multiple dumps on EXB-8200 8mm tape

5. Why so many ufsdump processes after I type "ufsdump 0f /dev/null /"?

6. Where Can I get Netscape Proxy?

7. part 1/2 of: running ufsdump under "script ufsdump.log"

8. Ygg LINUX & ftape

9. Ultra 1 170E OpenBoot Prom Question?

10. FS:Sun Ultra 1/170E Creator 3D Complete System ..

11. Solaris 2.3, Sparc 5 to Solaris 2.5, Ultra 170E upgrade

12. Help: Solaris Crashes in 1600x1280 res. mode in Ultra 170E machine

13. Real Time MPEG Compression on Ultra 170e