On Thu, Jul 24, 2008 at 03:34:26PM +0200, Robert Millan wrote: > On Thu, Jul 24, 2008 at 01:13:06AM +0100, Adeodato Simó wrote: > > > > > In addition 1.41.0 closed a large number of bugs over 1.40.11, and is > > > the first version to have ext4 support. > > Btw, a version of GRUB 2 with ext4dev support was just uploaded > (1.96+20080717-1).
I wouldn't dream of asking debian-boot to support ext4dev at this late date --- but there is one thing I would ask. As I recall, there was a temporary fix to force to use of 128 byte inodes for the interim etch release of the d-i. Could we make sure that temporary fix is removed for Lenny, so that by default new filesystems are created with 256 byte inodes? 256 byte inodes will significantly speed up Debian systems that use any of the following programs/technologies: Selinux, Samba4, trackerd, and/or ext4dev. Basically, any program that uses extended attributes (which is the reason for the first three items on that list) will be much faster with 256 byte inodes. Ext4dev uses the 256 byte inodes to support some of its various new features, such as nanosecond time resolution (important given that compilers can finish compiling a program in under a second), the creation timestamp, 64-bit i_version support for NFSv4, etc. The kernel has supported 256 byte inodes for a long time; the issue was merely Grub needed a specific patch for 128-byte inodes, and folks didn't want to patch grub for an interim etch release. I believe the grub patch *has* been in Lenny for quite some time, however. (There was one update to that patch to make sure really ancient revision 0 filesystems don't confuse grub.) - Ted Date: Tue, 22 Jul 2008 10:05:21 -0500 From: Eric Sandeen <[EMAIL PROTECTED]> User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) Subject: Re: Bug#491076: grub-install does not work [...] 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]