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% done,
>> finished in 1:19".  At the 5GB mark, ^T gives:
>> 
>>     load: 0.00  cmd: dump 3981 [physstr] 2.11u 43.06s 0% 1536k
>> 
>> and never changes.  The user and system times never advance.  Anybody
>> have any ideas?
> 
> 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: Invalid argument: [sector -1054739788]: 
>count=-1
>      DUMP: read error from /dev/ad0s5e: Invalid argument: [sector -1054739787]: 
>count=-1
>      DUMP: read error from /dev/ad0s5e: Invalid argument: [sector -1054739786]: 
>count=-1
>     
> and on and on. 
> 
> Maybe a 32 bit <--> 64 bit mismatch caused by UFS2?  My -current is of
> date=2002.06.27.22.00.00.

I'm not able to reproduce this here on a freshly built 11 GB filesystem.
It only contains about 2 GB of data, but the data is fairly uniformly
spread over all the cylinder groups.  I'm running a version of -current
built Fri Jul  5 13:07:05 PDT 2002, though I don't recall seeing any
likely looking commits since the first report of this problem.

I also looked at the source and didn't see anything suspicious, though I
did find some print format mismatches.





To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to