linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Theodore Tso <tytso@mit.edu>
To: Gary Hawco <ghawco@cox.net>
Cc: "linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>
Subject: Re: More ext4dev snapshot weirdness
Date: Tue, 1 Jul 2008 12:02:36 -0400	[thread overview]
Message-ID: <20080701160236.GG22717@mit.edu> (raw)
In-Reply-To: <3.0.6.32.20080701000046.025249e0@pop.west.cox.net>

On Tue, Jul 01, 2008 at 12:00:46AM +0000, Gary Hawco wrote:
> Gentoo was fine through 062508/00119hrs. No problems. From 062608/0042hrs -
> 062708/2353 snapshots boot sequence was fine, but segfaulting running my
> portage/metadata backup script (lots of small files).
> 
> Today's updates rebased against 2.6.26-rc8 are NOT segfaulting running the
> backup script, but seem to be corrupting the /lib/rc/init.d/database files
> after the first start.
> 
> I am willing to bet that Gentoo on the old baselayout/Non open-rc startup
> up scripts would have no problems ala Slackware, but it's curious
> everything was fine through the 062508/0019GMT snapshot. It seems that once
> delalloc was brought back in with ordered data mode problems started to
> arise. I tried to roll back the baselayout v2 to the older version 1.12,
> but I broke the os and had to quickly reinstall using a recent tarball.
> It's the only explanation why Gentoo is having problems, but Slackware is
> not. And now that today with the latest rc-8 snapshots the initialization
> of devices during startup is getting fubared, I am certain the
> Baselayout2/open-rc-2.5 does not like the latest iterations of the
> ext4-patch-queue kernel.

Gary,

It's definitely the case that kernel oops indicates kernel bugs.  It
might be the case that one distribution is better than another at
exposing the bug and making it visible, but that doesn't mean the bug
is in the distribution; in fact, if you can provoke a segfault, this
is *good* because it can help us track down the bug more
effectively/efficiently.  Data corruption like you are seeing now is
worse, since it's actually much harder to track down.

Of course, in order to track down the segfault we really need the oops
messages.  In the bad old days I would laborously copy down all of the
numbers and function names in the stack trace using pen and paper, and
then transcribe it into e-mail.  (Yes, I also walked uphill through
the snow in the winter, in both directions.  :-) Using a digital
camera is more convenient, but if it's too hard for you to grab one,
you can always fall back to the pen and paper model.

So if you have data corruption in your init.d files, does it go away
if you disable delalloc?  What if you disable mballoc?  Of course, do
this on Gentoo if it's better at provoking the filesystem bug.
Remember, from the point of view of filesystem developers, it's good
if you can provoke the bug; since it's only then that you can squash
it.  :-)

       	       		       	      	      - Ted

  reply	other threads:[~2008-07-01 16:02 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-25 13:53 Segmentation Faults with 062508 ext4-patch-queue snapshot Gary Hawco
2008-06-26  4:14 ` Eric Sandeen
2008-06-26 22:12   ` Segmentation Faults with both 062608 snapshots Gary Hawco
2008-07-01  2:32     ` Theodore Tso
2008-07-01  0:00       ` More ext4dev snapshot weirdness Gary Hawco
2008-07-01 16:02         ` Theodore Tso [this message]
2008-07-01 10:54           ` delalloc filesystem corruption Gary Hawco
2008-07-01 23:00             ` Mingming Cao
2008-07-01 17:50               ` Gentoo with ext4-patch-queue snapshots Gary Hawco
2008-07-02 17:19                 ` Mingming Cao
2008-07-02 20:33                   ` Mingming Cao
2008-07-03 14:07                     ` Aneesh Kumar
2008-07-03 17:38                       ` Mingming Cao

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=20080701160236.GG22717@mit.edu \
    --to=tytso@mit.edu \
    --cc=ghawco@cox.net \
    --cc=linux-ext4@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;
as well as URLs for NNTP newsgroup(s).