public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrea Arcangeli <andrea@suse.de>
To: Marc-Christian Petersen <m.c.p@wolk-project.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 01:59:39 +0100	[thread overview]
Message-ID: <20021203005939.GF28164@dualathlon.random> (raw)
In-Reply-To: <200212030059.32018.m.c.p@wolk-project.de>

On Tue, Dec 03, 2002 at 12:59:32AM +0100, Marc-Christian Petersen wrote:
> ext3_free_blocks: Freeing blocks not in datazone - block = 1530182

this is the interesting one. Did you run any unstable kernel/driver
software combination recently or maybe you got oopsed or crashes?

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
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
there are corruption issues in my current tree (and even the UP deadlock
that I fixed couldn't explain the corruption, in this case [the UP
deadlock] I'm sure because I know what kind of side effect _this_ bug could
generate, for any other crash you cannot tell if e2fsck -f is needed
until/unless you know the details of the bug, and most of the time you
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).

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.

Andrea

  reply	other threads:[~2002-12-03  0:52 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 [this message]
2002-12-03 10:13   ` Marc-Christian Petersen
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=20021203005939.GF28164@dualathlon.random \
    --to=andrea@suse.de \
    --cc=andrew@sol-1.demon.co.uk \
    --cc=jmarcet@pobox.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.c.p@wolk-project.de \
    /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