On Sun, 7 Jul 2002, Don Lewis wrote:
> On 7 Jul, Ian Dowse wrote:
> > Thanks for tracking this down! One thing is that the code was using
> > the static pointers to avoid having to malloc and free blocks every
> > time. Keeping an array of NIADDR pointers and using `ind_level' as
> > the index i
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 tes
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/ad0
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.
>
> Tha
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 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:
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:
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 properl
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 5
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 [physst
10 matches
Mail list logo