In message [EMAIL PROTECTED], Don Lewis writes:
I was finally finally able to reproduce this by creating a large file
before doing the dump. Dump(8) is *very* hosed. The UFS2 import broke
it's ability to follow multiple levels of indirect blocks.
Thanks for tracking this down! One thing
On 7 Jul, Ian Dowse wrote:
In message [EMAIL PROTECTED], Don Lewis writes:
I was finally finally able to reproduce this by creating a large file
before doing the dump. Dump(8) is *very* hosed. The UFS2 import broke
it's ability to follow multiple levels of indirect blocks.
Thanks
On Sat, 6 Jul 2002, Don Lewis wrote:
For me it is broken in a different way. For a small FS like / it works,
but dumping my /home, which is 4G, I get
DUMP: read error from /dev/ad0s5e: Invalid argument: [sector -1054739789]:
count=-1
DUMP: read error from /dev/ad0s5e:
On Sun, Jul 07, 2002 at 12:27:31PM +0100, Ian Dowse wrote:
I'll commit your printf format changes first anyway - thanks!
Just to make sure, you're not going to fix the problem dump problem; just
fix the bad screen output. Correct? Since I've got a very reproduceable
test case; I wanted to
On 5 Jul, Georg-W. Koltermann wrote:
Am Mi, 2002-07-03 um 17.31 schrieb David O'Brien:
On a 27-June-2002 23:02:00 UTC system (just before ipfw2 went in,
pre-KSE3), dump will not complete dumping more than 5GB. At that point
it stops responding properly to ^T, which should give DUMP: 47.52%
the dump. Dump(8) is *very* hosed. The UFS2 import broke
it's ability to follow multiple levels of indirect blocks.
Here's a patch that fixed the problem along with a bunch of print format
mismatches:
Index: tape.c
===
RCS file
Am Mi, 2002-07-03 um 17.31 schrieb David O'Brien:
On a 27-June-2002 23:02:00 UTC system (just before ipfw2 went in,
pre-KSE3), dump will not complete dumping more than 5GB. At that point
it stops responding properly to ^T, which should give DUMP: 47.52% done,
finished in 1:19. At the 5GB
On Fri, Jul 05, 2002 at 06:48:56PM +0200, Georg-W. Koltermann wrote:
Am Mi, 2002-07-03 um 17.31 schrieb David O'Brien:
On a 27-June-2002 23:02:00 UTC system (just before ipfw2 went in,
pre-KSE3), dump will not complete dumping more than 5GB. At that point
it stops responding properly to
On a 27-June-2002 23:02:00 UTC system (just before ipfw2 went in,
pre-KSE3), dump will not complete dumping more than 5GB. At that point
it stops responding properly to ^T, which should give DUMP: 47.52% done,
finished in 1:19. At the 5GB mark, ^T gives:
load: 0.00 cmd: dump 3981
