It built, it booted, and its busted big time. First, with an amdump
running in the background, the machine is so close to unusable that I
considered rebooting, but I needed the data to show the problem. I am
losing the keyboard and mouse for a minute or more at a time but the
keystrokes seem to be being registered so it eventually catches up.
Disk i/o seems to be the killer according to gkrellm.
But to give one an idea of the fits this is giving tar, I'll snip a line
or 2 from an amstatus report here:
coyote:/GenesAmandaHelper-0.6 1 planner: [dumps way too big, 138200 KB,
must skip incremental dumps]
Huh? 138.2GB? A 'du -h .' in that dir says 766megs.
coyote:/root 1 4426m wait for dumping
du -h says 5.0GB so that's ballpark, but its also a level 1, so maybe 20
megs is actually new since 15:57 this afternoon local. kmails final
maildir is in that dir.
This goes on for much of the amstatus report, very few of the reported
sizes are close to sane.
Now, can someone suggest a patch I can revert that might fix this? The
total number of patches between 2.6.20 and 2.6.21-rc1 will have me
building kernels to bisect this till the middle of June at this rate.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Is a tattoo real, like a curb or a battleship? Or are we suffering in
Safeway?
-
