Bug 22188 - ext3-0.0.5c:/ no problem; /home:not exactly
Summary: ext3-0.0.5c:/ no problem; /home:not exactly
Alias: None
Product: Red Hat High Availability Server
Classification: Retired
Component: ext3
Version: beta
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Stephen Tweedie
QA Contact: Wil Harris
Depends On:
TreeView+ depends on / blocked
Reported: 2000-12-12 22:59 UTC by angus young
Modified: 2007-04-18 16:30 UTC (History)
1 user (show)

Clone Of:
Last Closed: 2000-12-18 18:32:08 UTC

Attachments (Terms of Use)
dd bs=1k count=1 </home/journal.dat >/tmp/ext3.header : result (1.00 KB, application/octet-stream)
2000-12-14 20:32 UTC, angus young
no flags Details
dumpe2fs /dev/sdb8 >/tmp/sdb8.header : result (60.92 KB, application/octet-stream)
2000-12-14 22:27 UTC, angus young
no flags Details
Fix journal superblock initialisation (787 bytes, patch)
2000-12-18 12:28 UTC, Stephen Tweedie
no flags Details | Diff

Description angus young 2000-12-12 22:59:00 UTC
No problem with the / procedure to convert it to ext3
But for upgrading my /home filesystem to ext3:
fsck: Warning... fsck.ext3 for device /dev/sdb8 exited with signal 11.
rc.sysinit: Checking filesystems failed
fsck: : Filesystem has unsupported feature(s) /dev/sdb8: journal has
incompatible features

dd if=/dev/zero bs=1k count=10000 of=/home/journal.dat
ls -i /home/journal.dat
   3451 /home/journal.dat
chmod 400 /home/journal.dat
chattr +i /home/journal.dat
umount /home

cat /etc/fstab

LABEL=/1         /               ext3    noatime,nodiratime	1 1
/dev/sdb8        /home           ext3    defaults        	1 2

mount -t ext3 /dev/sdb8 /home -o journal=3451

no problem


and after the error message for /home mount like an ext3 partition

funniest is that when i attempt to mount /home manually like this
mount -t ext3 /dev/sdb8 /home

there is no problem

any idea ?

in spite of it nuisance I have the impression that that goes more quickly
with ext3.
i will do some bonnie benchmark quickly.

just want to tell you that recovery of my / was a true happiness
after a deliberated reset:
EXT3-fs: WARNING: recovery required on readonly filesystem.
EXT3-fs: write access will be enabled during recovery.
EXT3-fs: recovery complete
EXT3-fs: mounted filesystem with ordered data mode.
ouah, less than one second.

the first tests seem promising.
to be continued ;-)

Comment 1 Stephen Tweedie 2000-12-13 20:43:55 UTC
Which version of e2fsprogs were you running?  Did you get a core dump from it?

Comment 2 angus young 2000-12-13 21:06:30 UTC
like precise in README
no core dump from it
if i can give you some other information, tell me.

Comment 3 Stephen Tweedie 2000-12-13 21:30:57 UTC
e2fsck from that release really should know about all of the new feature bits.
Can you run debugfs on /dev/sdb8 and see what the "features" command says is
set? Do you get the problem if you just run e2fsck manually on the partition
after unmounting it?

Comment 4 angus young 2000-12-13 22:34:14 UTC
debugfs 1.20-WIP, 16-Nov-2000 for EXT2 FS 0.5b, 95/08/09
debugfs:  features
Filesystem features: has_journal filetype sparse_super
e2fsck result after umount /dev/sdb8:

Parallelizing fsck version 1.20-WIP (16-Nov-2000)
e2fsck 1.20-WIP, 16-Nov-2000 for EXT2 FS 0.5b, 95/08/09
fsck.ext3: Filesystem has unsupported feature(s) /dev/sdb8: journal has
incompatible features

fsck.ext3: Filesystem has unsupported feature(s) while checking ext3 journal for
Warning... fsck.ext3 for device /dev/sdb8 exited with signal 11.
to be continued

Comment 5 Stephen Tweedie 2000-12-14 17:35:54 UTC
OK, the SEGV needs to be fixed, but I can't see why you would be getting this
error in the first place.  Could you send me the header of both the journal (dd
bs=1k count=1 < /mnt/.../journal.dat > /tmp/ext3.header) and the filesystem
(debugfs /dev/sdb8)?  You can mail me directly or attach them to the bugzilla
report if you want.

Comment 6 angus young 2000-12-14 20:32:50 UTC
Created attachment 6416 [details]
dd bs=1k count=1 </home/journal.dat >/tmp/ext3.header : result

Comment 7 angus young 2000-12-14 20:44:24 UTC
what sort of command do i pass to debugfs for ouput header of /dev/sdb8

Comment 8 Stephen Tweedie 2000-12-14 20:50:58 UTC
Sorry, try "dumpe2fs" instead.

Comment 9 angus young 2000-12-14 22:27:42 UTC
Created attachment 6417 [details]
dumpe2fs /dev/sdb8 >/tmp/sdb8.header : result

Comment 10 angus young 2000-12-14 23:17:52 UTC
ext3-0.0.5d with 2.2.18 now.
same problem with fsck.

Comment 11 angus young 2000-12-16 14:43:08 UTC
set out again from scratch.
same problem with the upgrade of my /home partition
appears to be a problem with superblock of these partition.
fortunately, no problem to retrogress to ext2.
Currently, this is the only problem which I have with ext3-0.0.5d.
Have you indices with header's files given to you.

Comment 12 angus young 2000-12-17 16:44:26 UTC
take another partition to convert to ext3
same problem with fsck
is there similary reporting problem (than mine)for upgrading existing ext2

Comment 13 Stephen Tweedie 2000-12-18 12:28:48 UTC
Created attachment 6521 [details]
Fix journal superblock initialisation

Comment 14 Stephen Tweedie 2000-12-18 12:30:22 UTC
OK, there was a fairly obvious hole in the initialisation of the journal: I was
zeroing the whole of the journal except for the first block.  The attached patch
should fix it, as well as adding a couple of minor cleanups to the journal init

This will be in ext3-0.0.5e.

Comment 15 angus young 2000-12-18 18:31:59 UTC
sorry but this patch don' resolve the problem.
is not this a problem of e2fsprogs-1.20.WIP.sct-20001207.i386.rpm ?

Comment 16 Stephen Tweedie 2000-12-18 19:35:11 UTC
The journal header you provided has an uninitialised features field.  e2fsprogs
is (correctly) refusing to touch it because of the unexpected features flags.
The SEGV in e2fsprogs is definitely a bug, but it doesn't appear to be the same
one that is causing you trouble: a correctly-initialised journal would not cause
e2fsck to get confused in the first place!

There is another bug in the kernel which was that the compatibility flags were
not being correctly tested at mount time.  That bug was the only reason you were
ever able to mount the filesystem: e2fsprogs was actually doing the right thing
by refusing to fsck the device.

I'll look into the e2fsck SEGV as a separate bug, but the compatibility bug here
definitely looks like a kernel bug at source.

Note You need to log in before you can comment on or make changes to this bug.