Message-Id: <3.0.6.32.20080701000046.025249e0@pop.west.cox.net>
Date:	Tue, 01 Jul 2008 00:00:46
From:	Gary Hawco <ghawco@....net>
To:	Theodore Tso <tytso@....edu>,
	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: More ext4dev snapshot weirdness

Ted,

Did some more testing before replying.

Have two linux operating systems:

Both were setup identically, i.e, formatted with flex_bg & meta_bg. Tune2fs
used to enable uninit_bg. Ordered data mode. Grub used to pass boot
parameter of rootflags=commit=15. Fstab mount options of
noatime,nodiratime,journal_async_commit.

Slackware 12.1--this one uses its BSD style startup scripts. No problems
whatsoever with any of the snapshots including the newest from 30 June
2008/2219hrs.

Gentoo --this is the system I am having trouble with.

It will boot the snapshot from 062508/0019hrs fine.  Everything works fine
here including my script that updates the portage/metadata trees, copies
them to another partition setup identically with ext4dev, i.e. flex_bg,
meta_bg & uninit_bg, then creates a tarball.

All of the snapshots after the 062508 timestamp through the 062708/2353hrs.
snapshot would segfault running this script.  (Looking for a digital
camera, that uses flash media that windows or linux will recognize so I can
save and post the jpeg image)

Starting with today's snapshots rebased against 2.6.26-rc8 kernel a new
problem surfaced, and the old segfault issues disappeared.  That is, I
could run my script without any problems.

My Gentoo uses an updated baselayout/OpenRC start configuration.  It has a
/lib/rc folder as opposed to var/lib/init.d, containing several subfolders,
such as /lib/rc/init.d which cache dependencies and make for a very fast
boot and shutdown.

With today's snapshots I get one clean start, then I get errors where the
network interface eth0 does not initialize on startup but can manually be
pulled in by "dhcpcd eth0".  If I delete the contents of /lib/rc/init.d on
the next restart the network interface initializes properly.

If I roll back to the 062508 kernel snapshot, this new problem goes away.

I tried removing journal_async_commit from fstab mount options without any
difference.  I was also passing rootflags=commit=15 during bootup with
grub. I removed that parameter changing back to the default 5 second commit
interval without any improvement.  This new startup style uses parallel
service starts. I changed back to series starting without any improvement.
I even tried switching from ordered data mode to writeback mode without
success.

So if I haven't thoroughly confused you or put you to sleep, to summarize:

Slackware loves all the snapshots.

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.

Hope this expose sheds some light on things.

Thanks again,
Gary


--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists