Re: Exaggerated swap usage

[Andrea Arcangeli <andrea@suse.de>]

On Tue, Dec 03, 2002 at 11:13:22AM +0100, Marc-Christian Petersen wrote:
> On Tuesday 03 December 2002 01:59, you wrote:
> 
> Hi Andrea,
> 
> > this is the interesting one. Did you run any unstable kernel/driver
> > software combination recently or maybe you got oopsed or crashes?
> nope, no oops, no crash, afaik no unstable kernel/drivers. Kernel is yours ;) 
> and drivers, hmm, just intel i815, eepro100. That happend after some hours of 
> uptime and just doing "rm -rf linux-old"
> 
> > journaling sometime gives a false sense of reliability, you've to keep
> > in mind that unless you know why you had to reboot w/o a clean unmount
> > you should always force an e2fsck -f/reiserfsck in single user mode at
> > the next boot, no matter of journaling. If the machine crashed because
> Yep, I always do a forced fsck in case of that.
> 
> > of a kernel oops or similar skipping the filesystemcheck at the very
> > next boot could left the fs corrupted for a long time until you notice
> > it possibly while running an unrelated kernel. So if you crashed
> > recently and you didn't run any e2fsck -f that could explain it. I doubt
> I run e2fsck -fy every time after a crash. Fortunately it doesn't happen so 
> often :-)

ok ;) I asked just in case.

> 
> > ...
> > don't know the details of the bug at the time of the next reboot so
> > normally an e2fsck -f is always required after a kernel crash, this
> > can't be automated simply because if the kernel is crashed we can't
> > write to the superblock to notify e2fsck about it, so at the next boot
> > e2fsck will always think replying the log was enough).
> yep. I tried to remove that 00_umount-against-unused-dirty-inodes-race fix and 
> after that (now 5 hours uptime) doing only copying and deleting, that ext3fs 
> error is away.
> 
> > Of course your problem could be explained by a bad cable or whatever
> > else hardware failure too. At the moment I doubt it's a problem in the
> > common code of my tree or mainline.
> seems it's a problem in the umount-against-unused-dirty-inodes-race fix or if 
> the fix "is the right way" the problem is located somewhere else what 
> triggers the problem of your patch.

can you reproduce in 2.4.20aa1 too?

Andrea