From: Marc-Christian Petersen <m.c.p@wolk-project.de>
To: Andrea Arcangeli <andrea@suse.de>
Cc: linux-kernel@vger.kernel.org,
Andrew Clayton <andrew@sol-1.demon.co.uk>,
Javier Marcet <jmarcet@pobox.com>
Subject: Re: Exaggerated swap usage
Date: Tue, 3 Dec 2002 11:13:22 +0100 [thread overview]
Message-ID: <200212031112.14635.m.c.p@wolk-project.de> (raw)
In-Reply-To: <20021203005939.GF28164@dualathlon.random>
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 :-)
> ...
> 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.
ciao, Marc
next prev parent reply other threads:[~2002-12-03 10:06 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-02 23:59 Exaggerated swap usage Marc-Christian Petersen
2002-12-03 0:59 ` Andrea Arcangeli
2002-12-03 10:13 ` Marc-Christian Petersen [this message]
2002-12-03 13:59 ` Andrea Arcangeli
2002-12-03 18:43 ` Marc-Christian Petersen
2002-12-05 23:14 ` Marc-Christian Petersen
-- strict thread matches above, loose matches on Subject: below --
2002-11-29 15:28 Randal, Phil
2002-11-29 16:28 ` Rik van Riel
2002-11-29 11:54 Javier Marcet
2002-11-29 12:20 ` Christer Nilsson
2002-11-29 16:31 ` Rik van Riel
2002-11-30 1:38 ` Javier Marcet
2002-11-30 1:55 ` Rik van Riel
2002-11-30 2:47 ` Zwane Mwaikambo
2002-11-30 5:17 ` Javier Marcet
2002-11-30 2:42 ` Zwane Mwaikambo
2002-11-30 3:02 ` Andrew Morton
2002-11-30 4:12 ` Zwane Mwaikambo
2002-11-30 6:48 ` khromy
2002-11-30 6:49 ` Javier Marcet
2002-11-30 7:08 ` Dmitri
2002-11-30 14:05 ` Javier Marcet
2002-11-30 18:23 ` khromy
2002-11-30 18:43 ` Andrea Arcangeli
2002-12-01 7:39 ` Javier Marcet
2002-12-01 7:53 ` Javier Marcet
2002-12-01 10:34 ` Andrea Arcangeli
2002-12-01 7:59 ` Javier Marcet
2002-12-01 10:36 ` Andrea Arcangeli
2002-12-01 14:37 ` Nuno Monteiro
2002-12-02 0:21 ` Andrea Arcangeli
2002-12-02 1:01 ` Nuno Monteiro
2002-12-02 4:55 ` Javier Marcet
2002-12-02 21:24 ` Andrew Clayton
2002-11-30 14:05 ` Steffen Moser
2002-11-30 18:22 ` Rik van Riel
2002-12-01 7:57 ` Javier Marcet
2002-12-01 19:27 ` Rik van Riel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200212031112.14635.m.c.p@wolk-project.de \
--to=m.c.p@wolk-project.de \
--cc=andrea@suse.de \
--cc=andrew@sol-1.demon.co.uk \
--cc=jmarcet@pobox.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox