Bug 22188 - ext3-0.0.5c:/ no problem; /home:not exactly
ext3-0.0.5c:/ no problem; /home:not exactly
Status: CLOSED CURRENTRELEASE
Product: Red Hat High Availability Server
Classification: Retired
Component: ext3 (Show other bugs)
beta
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Stephen Tweedie
Wil Harris
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-12-12 17:59 EST by angus young
Modified: 2007-04-18 12:30 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-12-18 13:32:08 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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 15:32 EST, angus young
no flags Details
dumpe2fs /dev/sdb8 >/tmp/sdb8.header : result (60.92 KB, application/octet-stream)
2000-12-14 17:27 EST, angus young
no flags Details
Fix journal superblock initialisation (787 bytes, patch)
2000-12-18 07:28 EST, Stephen Tweedie
no flags Details | Diff

  None (edit)
Description angus young 2000-12-12 17:59:00 EST
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

reboot

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 15:43:55 EST
Which version of e2fsprogs were you running?  Did you get a core dump from it?
Comment 2 angus young 2000-12-13 16:06:30 EST
e2fsprogs-1.20.WIP.sct-20001207.i386.rpm
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 16:30:57 EST
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 17:34:14 EST
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
/dev/sdb8
Warning... fsck.ext3 for device /dev/sdb8 exited with signal 11.
------------------------------------------------------------------
to be continued
Comment 5 Stephen Tweedie 2000-12-14 12:35:54 EST
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 15:32:50 EST
Created attachment 6416 [details]
dd bs=1k count=1 </home/journal.dat >/tmp/ext3.header : result
Comment 7 angus young 2000-12-14 15:44:24 EST
what sort of command do i pass to debugfs for ouput header of /dev/sdb8
partition?
Comment 8 Stephen Tweedie 2000-12-14 15:50:58 EST
Sorry, try "dumpe2fs" instead.
Comment 9 angus young 2000-12-14 17:27:42 EST
Created attachment 6417 [details]
dumpe2fs /dev/sdb8 >/tmp/sdb8.header : result
Comment 10 angus young 2000-12-14 18:17:52 EST
ext3-0.0.5d with 2.2.18 now.
same problem with fsck.
Comment 11 angus young 2000-12-16 09:43:08 EST
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 11:44:26 EST
take another partition to convert to ext3
same problem with fsck
is there similary reporting problem (than mine)for upgrading existing ext2
partition?
Comment 13 Stephen Tweedie 2000-12-18 07:28:48 EST
Created attachment 6521 [details]
Fix journal superblock initialisation
Comment 14 Stephen Tweedie 2000-12-18 07:30:22 EST
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
code.

This will be in ext3-0.0.5e.
Comment 15 angus young 2000-12-18 13:31:59 EST
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 14:35:11 EST
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.