Stefan Lippers-Hollmann wrote:
> Hi
>
> On Dienstag, 22. Juli 2008, [EMAIL PROTECTED] wrote:
> [...]
>
>>> Are you sure -29 worked but -30 didn't? This would indicate
>>> ext3_256byte_inode.diff introduced this regression.
>>>
>>> Which version of e2fsprogs did you use to create that ext2fs?
>>> (and with
>>> which flags)
>>>
>> the filesystem is created with an unsupported closed source replication
>> tool which name i prefer not to write ;-). all i can tell you now is that
>> the filesystem is ext2 and that it seems clean (i can execute without
>> problems find, apt-get, etc.)
>>
>> i'm on holydays but maybe this afternoon i can make a raid into the
>> office and get some extra info...
>>
>
> If you do that, I would suggest running a native e2fsck on the ext2
> filesystem (or better a copy of it), just to rule out filesystem
> corruption.
>
> While I'm not an expert on ext2 filesystem semantics, s_inode_size getting
> 0 sounds a bit strange. Of particular interest seems to be the follow
> paragraph from http://e2fsprogs.sourceforge.net/e2fsprogs-release.html
>
> Make the e2fsprogs program more robust so that they will not crash
> when opening a corrupt filesystem where s_inode_size is zero.
>
> Which seems to suggest that the filesystem is indeed corrupt, but that
> it might also be a rather common corruption?
>
> Regards
> Stefan Lippers-Hollmann
>
There was a bug in the large inode support that I added to grub, which other
distros picked up from red hat. The following patch should fix it: (apologies
for likely email patch-mangling)
-------- Original Message --------
Subject: Broken inode_size handling in grub-fedora-9.patch
Date: Mon, 21 Jul 2008 01:40:25 -0600
From: RB <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Just thought I'd give you a heads-up: I was working on Gentoo bug
#220687 and I ran into an issue with a patch we seem to have gotten
from you guys, by way of Debian.
In stage2/fsys_ext2fs.c (on line 38552 of your patch), you add a macro
to find EXT2_INODE_SIZE by just pulling it from the superblock.
Unfortunately, in the non-dynamic revision of ext2 that space is
zero-padded and the result is a floating-point exception when
attempting to boot from any old-style ext2 images. Boot-time div/0
failures are a blast to debug... :)
This is a rough patch against your patch with more code sucked out of
linux/ext2_fs.h - I have no way to test it against a fedora system and
it's a little chunky/odd, but it should give you an idea of what seems
to be the fix. It compiles and runs happily on my systems. Thanks
for your time!
RB
============================
--- grub-fedora-9.patch 2008-07-21 01:26:34.454960640 -0600
+++ grub-fedora-9-fixed.patch 2008-07-21 01:35:18.343451893 -0600
@@ -38529,7 +38529,7 @@
};
struct ext2_group_desc
-@@ -206,18 +251,21 @@ struct ext2_dir_entry
+@@ -206,18 +251,26 @@ struct ext2_dir_entry
((struct ext2_super_block *)(FSYS_BUF))
#define GROUP_DESC \
((struct ext2_group_desc *) \
@@ -38549,7 +38549,12 @@
#define EXT2_ADDR_PER_BLOCK(s) (EXT2_BLOCK_SIZE(s) / sizeof (__u32))
#define EXT2_ADDR_PER_BLOCK_BITS(s) (log2(EXT2_ADDR_PER_BLOCK(s)))
-+#define EXT2_INODE_SIZE(s) (SUPERBLOCK->s_inode_size)
++#define EXT2_GOOD_OLD_REV 0 /* The good old (original) format */
++#define EXT2_DYNAMIC_REV 1 /* V2 format w/ dynamic inode sizes */
++#define EXT2_GOOD_OLD_INODE_SIZE 128
++#define EXT2_INODE_SIZE(s) (((s)->s_rev_level == EXT2_GOOD_OLD_REV) ? \
++ EXT2_GOOD_OLD_INODE_SIZE : \
++ (s)->s_inode_size)
+#define EXT2_INODES_PER_BLOCK(s)
(EXT2_BLOCK_SIZE(s)/EXT2_INODE_SIZE(s))
+
/* linux/ext2_fs.h */
-- Peter
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
