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
