* [PATCH] ext4 extent support
@ 2008-07-04 17:59 Bean
2008-07-04 18:39 ` Robert Millan
` (3 more replies)
0 siblings, 4 replies; 21+ messages in thread
From: Bean @ 2008-07-04 17:59 UTC (permalink / raw)
To: The development of GRUB 2
[-- Attachment #1: Type: text/plain, Size: 59 bytes --]
Hi,
This patch add support for extents in ext4.
--
Bean
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: extent.diff --]
[-- Type: text/x-diff; name=extent.diff, Size: 3839 bytes --]
diff --git a/fs/ext2.c b/fs/ext2.c
index 22fd272..3518dcf 100644
--- a/fs/ext2.c
+++ b/fs/ext2.c
@@ -86,6 +86,8 @@
#define EXT3_JOURNAL_FLAG_DELETED 4
#define EXT3_JOURNAL_FLAG_LAST_TAG 8
+#define EXT4_EXTENTS_FLAG 0x80000
+
/* The ext2 superblock. */
struct grub_ext2_sblock
{
@@ -226,6 +228,33 @@ struct grub_ext3_journal_sblock
grub_uint32_t start;
};
+#define EXT4_EXT_MAGIC 0xf30a
+
+struct grub_ext4_extent_header
+{
+ grub_uint16_t magic;
+ grub_uint16_t entries;
+ grub_uint16_t max;
+ grub_uint16_t depth;
+ grub_uint32_t generation;
+};
+
+struct grub_ext4_extent
+{
+ grub_uint32_t block;
+ grub_uint16_t len;
+ grub_uint16_t start_hi;
+ grub_uint32_t start;
+};
+
+struct grub_ext4_extent_idx
+{
+ grub_uint32_t block;
+ grub_uint32_t leaf;
+ grub_uint16_t leaf_hi;
+ grub_uint16_t unused;
+};
+
struct grub_fshelp_node
{
struct grub_ext2_data *data;
@@ -262,6 +291,46 @@ grub_ext2_blockgroup (struct grub_ext2_data *data, int group,
sizeof (struct grub_ext2_block_group), (char *) blkgrp);
}
+static struct grub_ext4_extent_header *
+grub_ext4_find_leaf (struct grub_ext2_data *data,
+ struct grub_ext4_extent_header *ext_block,
+ grub_uint32_t fileblock)
+{
+ char buf[EXT2_BLOCK_SIZE(data)];
+ struct grub_ext4_extent_idx *index;
+
+ while (1)
+ {
+ int i;
+ grub_disk_addr_t block;
+
+ index = (struct grub_ext4_extent_idx *) (ext_block + 1);
+
+ if (grub_le_to_cpu16(ext_block->magic) != EXT4_EXT_MAGIC)
+ return 0;
+
+ if (ext_block->depth == 0)
+ return ext_block;
+
+ for (i = 0; i < grub_le_to_cpu16 (ext_block->entries); i++)
+ {
+ if (fileblock < grub_le_to_cpu32(index[i].block))
+ break;
+ }
+
+ if (i == 0)
+ return 0;
+
+ block = grub_le_to_cpu16 (index[i].leaf_hi);
+ block = (block << 32) + grub_le_to_cpu32 (index[i].leaf);
+ if (grub_disk_read (data->disk,
+ block << LOG2_EXT2_BLOCK_SIZE (data),
+ 0, sizeof (buf), buf))
+ return 0;
+
+ ext_block = (struct grub_ext4_extent_header *) buf;
+ }
+}
static grub_disk_addr_t
grub_ext2_read_block (grub_fshelp_node_t node, grub_disk_addr_t fileblock)
@@ -272,6 +341,41 @@ grub_ext2_read_block (grub_fshelp_node_t node, grub_disk_addr_t fileblock)
unsigned int blksz = EXT2_BLOCK_SIZE (data);
int log2_blksz = LOG2_EXT2_BLOCK_SIZE (data);
+ if (inode->flags & EXT4_EXTENTS_FLAG)
+ {
+ struct grub_ext4_extent_header *leaf;
+ struct grub_ext4_extent *ext;
+ int i;
+
+ leaf = grub_ext4_find_leaf (data,
+ (struct grub_ext4_extent_header *) inode->blocks.dir_blocks,
+ fileblock);
+ if (! leaf)
+ {
+ grub_error (GRUB_ERR_BAD_FS, "invalid extent");
+ return -1;
+ }
+
+ ext = (struct grub_ext4_extent *) (leaf + 1);
+ for (i = 0; i < grub_le_to_cpu16 (leaf->entries); i++)
+ if ((fileblock >= grub_le_to_cpu32 (ext[i].block)) &&
+ (fileblock < grub_le_to_cpu32 (ext[i].block) +
+ grub_le_to_cpu16 (ext[i].len)) &&
+ ((grub_le_to_cpu16 (ext[i].len) >> 15) == 0))
+ {
+ grub_disk_addr_t start;
+
+ start = grub_le_to_cpu16 (ext[i].start_hi);
+ start = (start << 32) + grub_le_to_cpu32 (ext[i].start);
+ return fileblock - grub_le_to_cpu32 (ext[i].block) + start;
+ }
+
+
+
+ grub_printf ("HH\n");
+ return grub_error (GRUB_ERR_NOT_IMPLEMENTED_YET,
+ "ext2fs doesn't support extents");
+ }
/* Direct blocks. */
if (fileblock < INDIRECT_BLOCKS)
blknr = grub_le_to_cpu32 (inode->blocks.dir_blocks[fileblock]);
^ permalink raw reply related [flat|nested] 21+ messages in thread* Re: [PATCH] ext4 extent support 2008-07-04 17:59 [PATCH] ext4 extent support Bean @ 2008-07-04 18:39 ` Robert Millan 2008-07-04 18:47 ` Bean 2008-07-05 9:39 ` Felix Zielcke ` (2 subsequent siblings) 3 siblings, 1 reply; 21+ messages in thread From: Robert Millan @ 2008-07-04 18:39 UTC (permalink / raw) To: The development of GRUB 2 On Sat, Jul 05, 2008 at 01:59:56AM +0800, Bean wrote: > Hi, > > This patch add support for extents in ext4. Nice.. how big is the size increase? I wonder if it would make sense to to split it in a separate module using a hook or a build system hack. Or maybe this is overkill.. -- Robert Millan <GPLv2> I know my rights; I want my phone call! <DRM> What good is a phone call… if you are unable to speak? (as seen on /.) ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] ext4 extent support 2008-07-04 18:39 ` Robert Millan @ 2008-07-04 18:47 ` Bean 0 siblings, 0 replies; 21+ messages in thread From: Bean @ 2008-07-04 18:47 UTC (permalink / raw) To: The development of GRUB 2 On Sat, Jul 5, 2008 at 2:39 AM, Robert Millan <rmh@aybabtu.com> wrote: > On Sat, Jul 05, 2008 at 01:59:56AM +0800, Bean wrote: >> Hi, >> >> This patch add support for extents in ext4. > > Nice.. how big is the size increase? I wonder if it would make sense to > to split it in a separate module using a hook or a build system hack. > > Or maybe this is overkill.. Hi, There is not much code, I think it's not necessary to split it. -- Bean ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] ext4 extent support 2008-07-04 17:59 [PATCH] ext4 extent support Bean 2008-07-04 18:39 ` Robert Millan @ 2008-07-05 9:39 ` Felix Zielcke 2008-07-05 13:25 ` Javier Martín 2008-07-05 11:01 ` Marco Gerards 2008-07-10 21:30 ` Felix Zielcke 3 siblings, 1 reply; 21+ messages in thread From: Felix Zielcke @ 2008-07-05 9:39 UTC (permalink / raw) To: The development of GRUB 2 From: "Bean" <bean123ch@gmail.com> Sent: Friday, July 04, 2008 7:59 PM To: "The development of GRUB 2" <grub-devel@gnu.org> Subject: [PATCH] ext4 extent support > Hi, > > This patch add support for extents in ext4. > Thanks for the patch.I just tested it GRUB now works fine with 31 MB /boot ext4 with extent and flex_bg, though flex_bg shouldn't make a difference on that small partiton With uninit_bg enabled, which isn't by default enabled by e2fsprogs 1.41WIP, GRUB loaded but failed to load my Linux kernel with "can't read linux header" Once I had GRUB failing with file not found and then going to rescue mode but I think I did something wrong. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] ext4 extent support 2008-07-05 9:39 ` Felix Zielcke @ 2008-07-05 13:25 ` Javier Martín 2008-07-05 17:15 ` Felix Zielcke 0 siblings, 1 reply; 21+ messages in thread From: Javier Martín @ 2008-07-05 13:25 UTC (permalink / raw) To: The development of GRUB 2 [-- Attachment #1: Type: text/plain, Size: 394 bytes --] El sáb, 05-07-2008 a las 11:39 +0200, Felix Zielcke escribió: > GRUB now works fine with 31 MB /boot ext4 with extent Wonderful!! Bean, you're awesome! > and flex_bg, though > flex_bg shouldn't make a difference on that small partiton I think flex_bg support is unimplemented right now (at least I didn't see it anywhere), but it "worked" because it's not being used? Just a guess [-- Attachment #2: Esta parte del mensaje está firmada digitalmente --] [-- Type: application/pgp-signature, Size: 827 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] ext4 extent support 2008-07-05 13:25 ` Javier Martín @ 2008-07-05 17:15 ` Felix Zielcke 2008-07-05 18:09 ` Javier Martín 0 siblings, 1 reply; 21+ messages in thread From: Felix Zielcke @ 2008-07-05 17:15 UTC (permalink / raw) To: The development of GRUB 2 From: "JavierMartín" <lordhabbit@gmail.com> Sent: Saturday, July 05, 2008 3:25 PM To: "The development of GRUB 2" <grub-devel@gnu.org> Subject: Re: [PATCH] ext4 extent support >I think flex_bg support is unimplemented right now (at least I didn't >see it anywhere), but it "worked" because it's not being used? Just a >guess I just checked. Kernel 2.6.26-rc8 has a bit code with flex_bg e2fsprogs 1.41WIP from Debian experimantel has a bit more code with flex (not much with flex_bg more flexbg or just _flex) But I don't know much C so I don't understand the code :) Anyway I think the most important ext4 support are extents, because you can enable them by just remounting to ext4 as long as you don't use noextents mount option flex_bg can only be enabled by mkfs.ext4(dev) not afterwards with tune2fs but it's default enabled in mke2fs.conf for ext4(dev) uninit_bg isn't enabled by default and can be enabled afterwards with tune2fs but resize2fs isn't currently working with it ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] ext4 extent support 2008-07-05 17:15 ` Felix Zielcke @ 2008-07-05 18:09 ` Javier Martín 2008-07-06 4:51 ` Bean 2008-07-06 8:44 ` Felix Zielcke 0 siblings, 2 replies; 21+ messages in thread From: Javier Martín @ 2008-07-05 18:09 UTC (permalink / raw) To: The development of GRUB 2 [-- Attachment #1: Type: text/plain, Size: 1588 bytes --] El sáb, 05-07-2008 a las 19:15 +0200, Felix Zielcke escribió: > From: "JavierMartín" <lordhabbit@gmail.com> > Sent: Saturday, July 05, 2008 3:25 PM > To: "The development of GRUB 2" <grub-devel@gnu.org> > Subject: Re: [PATCH] ext4 extent support > > >I think flex_bg support is unimplemented right now (at least I didn't > >see it anywhere), but it "worked" because it's not being used? Just a > >guess > > I just checked. > Kernel 2.6.26-rc8 has a bit code with flex_bg > e2fsprogs 1.41WIP from Debian experimantel has a bit more code with flex > (not much with flex_bg more flexbg or just _flex) > But I don't know much C so I don't understand the code :) > Anyway I think the most important ext4 support are extents, because you can > enable them by just remounting to ext4 as long as you don't use noextents > mount option > flex_bg can only be enabled by mkfs.ext4(dev) not afterwards with tune2fs > but it's default enabled in mke2fs.conf for ext4(dev) > uninit_bg isn't enabled by default and can be enabled afterwards with > tune2fs but resize2fs isn't currently working with it I mean unimplemented in GRUB right now. IIrc, flex_bg relaxes some of the rules governing the location of the metadata block groups or something like that, so that they can be placed in "arbitrary" locations. Uninit_bg allows yet-unused block groups and inode tables to be initalized on first use, and saves a lot of time in mkfs (because it doesn't have to write all the inode tables) and fsck (because there's no need to check unused block groups at all). [-- Attachment #2: Esta parte del mensaje está firmada digitalmente --] [-- Type: application/pgp-signature, Size: 827 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] ext4 extent support 2008-07-05 18:09 ` Javier Martín @ 2008-07-06 4:51 ` Bean 2008-07-06 13:12 ` Felix Zielcke 2008-07-06 8:44 ` Felix Zielcke 1 sibling, 1 reply; 21+ messages in thread From: Bean @ 2008-07-06 4:51 UTC (permalink / raw) To: The development of GRUB 2 On Sun, Jul 6, 2008 at 2:09 AM, Javier Martín <lordhabbit@gmail.com> wrote: > El sáb, 05-07-2008 a las 19:15 +0200, Felix Zielcke escribió: >> From: "JavierMartín" <lordhabbit@gmail.com> >> Sent: Saturday, July 05, 2008 3:25 PM >> To: "The development of GRUB 2" <grub-devel@gnu.org> >> Subject: Re: [PATCH] ext4 extent support >> >> >I think flex_bg support is unimplemented right now (at least I didn't >> >see it anywhere), but it "worked" because it's not being used? Just a >> >guess >> >> I just checked. >> Kernel 2.6.26-rc8 has a bit code with flex_bg >> e2fsprogs 1.41WIP from Debian experimantel has a bit more code with flex >> (not much with flex_bg more flexbg or just _flex) >> But I don't know much C so I don't understand the code :) >> Anyway I think the most important ext4 support are extents, because you can >> enable them by just remounting to ext4 as long as you don't use noextents >> mount option >> flex_bg can only be enabled by mkfs.ext4(dev) not afterwards with tune2fs >> but it's default enabled in mke2fs.conf for ext4(dev) >> uninit_bg isn't enabled by default and can be enabled afterwards with >> tune2fs but resize2fs isn't currently working with it > I mean unimplemented in GRUB right now. IIrc, flex_bg relaxes some of > the rules governing the location of the metadata block groups or > something like that, so that they can be placed in "arbitrary" > locations. Hi, I found the description of flex_bg: This feature relaxes check restrictions on where each block groups meta data is located within the storage media. This allows for the allocation of bitmaps or inode tables outside the block group boundaries in cases where bad blocks forces us to look for new blocks which the owning block group can not satisfy. This will also allow for new meta-data allocation schemes to improve performance and scalability. The reallocation only occurs when bad blocks force us to use another block group, which is quite rare. So we should silently ignore this flag. -- Bean ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] ext4 extent support 2008-07-06 4:51 ` Bean @ 2008-07-06 13:12 ` Felix Zielcke 0 siblings, 0 replies; 21+ messages in thread From: Felix Zielcke @ 2008-07-06 13:12 UTC (permalink / raw) To: The development of GRUB 2 From: "Bean" <bean123ch@gmail.com> Sent: Sunday, July 06, 2008 6:51 AM To: "The development of GRUB 2" <grub-devel@gnu.org> Subject: Re: [PATCH] ext4 extent support > I found the description of flex_bg: > > This feature relaxes check restrictions on where each block groups meta > data is > located within the storage media. This allows for the allocation of > bitmaps or > inode tables outside the block group boundaries in cases where bad blocks > forces > us to look for new blocks which the owning block group can not satisfy. > This > will also allow for new meta-data allocation schemes to improve > performance and > scalability. > > The reallocation only occurs when bad blocks force us to use another > block group, which is quite rare. So we should silently ignore this > flag. > Hm, I just saw that there's a next branch in Tytso's ext4 git tree [1] I always looked at the normal HEAD tree or whatever it's called on git, I don't know much about git slang :) There in Documentation/filesystems/ext4.txt it says: * ability to pack bitmaps and inode tables into larger virtual groups via the flex_bg feature * Inode allocation using large virtual block groups via flex_bg mke2fs man page [2] says: Allow bitmaps and inode tables for a block group to be placed anywhere on the storage media (use with -G option to group meta-data in order to create a large virtual block group). But because I don't know what that exactly means I'm not sure if GRUB code needs to be a bit changed for it or not :) [1] http://git.kernel.org/?p=linux/kernel/git/tytso/ext4.git;a=tree;h=next;hb=next [2] http://git.kernel.org/?p=fs/ext2/e2fsprogs.git;a=blob;f=misc/mke2fs.8.in;hb=HEAD ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] ext4 extent support 2008-07-05 18:09 ` Javier Martín 2008-07-06 4:51 ` Bean @ 2008-07-06 8:44 ` Felix Zielcke 1 sibling, 0 replies; 21+ messages in thread From: Felix Zielcke @ 2008-07-06 8:44 UTC (permalink / raw) To: The development of GRUB 2 -------------------------------------------------- From: "JavierMartín" <lordhabbit@gmail.com> Sent: Saturday, July 05, 2008 8:09 PM To: "The development of GRUB 2" <grub-devel@gnu.org> Subject: Re: [PATCH] ext4 extent support > I mean unimplemented in GRUB right now. Ah yeah of course :) > IIrc, flex_bg relaxes some of > the rules governing the location of the metadata block groups or > something like that, so that they can be placed in "arbitrary" > locations. > Uninit_bg allows yet-unused block groups and inode tables to be > initalized on first use, and saves a lot of time in mkfs (because it > doesn't have to write all the inode tables) and fsck (because there's > no > need to check unused block groups at all). Yeah I read sth. about these ext4 features before I started to try it out. But I thought extN on a small new created filesystem with no deleted files works like inode/block 0 to x is used and x+1 to end is unused so it shouldn't make a difference with uninit_bg enabled or not GRUB wouldn't get to these unused inodes/blocks Seems like there's still much I could learn :) Oh and by the way http://tytso.livejournal.com/57492.html The ext4 developer is now using ext4 as primary fs on his notebook and he says it should be in a few weeks ready to be used for production data So seems like not a bad Idea to think about ext4 support in GRUB :) I only had problems with 2.6.25 Kernel. Since I switched from that one to 2.6.26-rc7 ext4 worked fine But I only use it in a VMware test system which isn't used much ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] ext4 extent support 2008-07-04 17:59 [PATCH] ext4 extent support Bean 2008-07-04 18:39 ` Robert Millan 2008-07-05 9:39 ` Felix Zielcke @ 2008-07-05 11:01 ` Marco Gerards 2008-07-05 17:25 ` Bean 2008-07-10 21:30 ` Felix Zielcke 3 siblings, 1 reply; 21+ messages in thread From: Marco Gerards @ 2008-07-05 11:01 UTC (permalink / raw) To: The development of GRUB 2 Hi Bean, Bean <bean123ch@gmail.com> writes: > This patch add support for extents in ext4. This is really great! :D Can you also provide a changelog entry? > diff --git a/fs/ext2.c b/fs/ext2.c > index 22fd272..3518dcf 100644 > --- a/fs/ext2.c > +++ b/fs/ext2.c > @@ -86,6 +86,8 @@ > #define EXT3_JOURNAL_FLAG_DELETED 4 > #define EXT3_JOURNAL_FLAG_LAST_TAG 8 > > +#define EXT4_EXTENTS_FLAG 0x80000 > + > /* The ext2 superblock. */ > struct grub_ext2_sblock > { > @@ -226,6 +228,33 @@ struct grub_ext3_journal_sblock > grub_uint32_t start; > }; > > +#define EXT4_EXT_MAGIC 0xf30a > + > +struct grub_ext4_extent_header > +{ > + grub_uint16_t magic; > + grub_uint16_t entries; > + grub_uint16_t max; > + grub_uint16_t depth; > + grub_uint32_t generation; > +}; > + > +struct grub_ext4_extent > +{ > + grub_uint32_t block; > + grub_uint16_t len; > + grub_uint16_t start_hi; > + grub_uint32_t start; > +}; > + > +struct grub_ext4_extent_idx > +{ > + grub_uint32_t block; > + grub_uint32_t leaf; > + grub_uint16_t leaf_hi; > + grub_uint16_t unused; > +}; > + > struct grub_fshelp_node > { > struct grub_ext2_data *data; > @@ -262,6 +291,46 @@ grub_ext2_blockgroup (struct grub_ext2_data *data, int group, > sizeof (struct grub_ext2_block_group), (char *) blkgrp); > } > > +static struct grub_ext4_extent_header * > +grub_ext4_find_leaf (struct grub_ext2_data *data, > + struct grub_ext4_extent_header *ext_block, > + grub_uint32_t fileblock) > +{ > + char buf[EXT2_BLOCK_SIZE(data)]; > + struct grub_ext4_extent_idx *index; > + > + while (1) > + { > + int i; > + grub_disk_addr_t block; > + > + index = (struct grub_ext4_extent_idx *) (ext_block + 1); > + > + if (grub_le_to_cpu16(ext_block->magic) != EXT4_EXT_MAGIC) > + return 0; > + > + if (ext_block->depth == 0) > + return ext_block; > + > + for (i = 0; i < grub_le_to_cpu16 (ext_block->entries); i++) > + { > + if (fileblock < grub_le_to_cpu32(index[i].block)) > + break; > + } > + > + if (i == 0) > + return 0; > + > + block = grub_le_to_cpu16 (index[i].leaf_hi); > + block = (block << 32) + grub_le_to_cpu32 (index[i].leaf); > + if (grub_disk_read (data->disk, > + block << LOG2_EXT2_BLOCK_SIZE (data), > + 0, sizeof (buf), buf)) > + return 0; > + > + ext_block = (struct grub_ext4_extent_header *) buf; > + } > +} > > static grub_disk_addr_t > grub_ext2_read_block (grub_fshelp_node_t node, grub_disk_addr_t fileblock) > @@ -272,6 +341,41 @@ grub_ext2_read_block (grub_fshelp_node_t node, grub_disk_addr_t fileblock) > unsigned int blksz = EXT2_BLOCK_SIZE (data); > int log2_blksz = LOG2_EXT2_BLOCK_SIZE (data); > > + if (inode->flags & EXT4_EXTENTS_FLAG) > + { > + struct grub_ext4_extent_header *leaf; > + struct grub_ext4_extent *ext; > + int i; > + > + leaf = grub_ext4_find_leaf (data, > + (struct grub_ext4_extent_header *) inode->blocks.dir_blocks, > + fileblock); > + if (! leaf) > + { > + grub_error (GRUB_ERR_BAD_FS, "invalid extent"); > + return -1; > + } > + > + ext = (struct grub_ext4_extent *) (leaf + 1); > + for (i = 0; i < grub_le_to_cpu16 (leaf->entries); i++) > + if ((fileblock >= grub_le_to_cpu32 (ext[i].block)) && > + (fileblock < grub_le_to_cpu32 (ext[i].block) + > + grub_le_to_cpu16 (ext[i].len)) && > + ((grub_le_to_cpu16 (ext[i].len) >> 15) == 0)) > + { > + grub_disk_addr_t start; > + > + start = grub_le_to_cpu16 (ext[i].start_hi); > + start = (start << 32) + grub_le_to_cpu32 (ext[i].start); > + return fileblock - grub_le_to_cpu32 (ext[i].block) + start; > + } > + > + > + > + grub_printf ("HH\n"); Whoops? ;-) > + return grub_error (GRUB_ERR_NOT_IMPLEMENTED_YET, > + "ext2fs doesn't support extents"); Why the error? I thought you have added extent support? Doesn't this mean the extent has another error of some kind? -- Marco ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] ext4 extent support 2008-07-05 11:01 ` Marco Gerards @ 2008-07-05 17:25 ` Bean 0 siblings, 0 replies; 21+ messages in thread From: Bean @ 2008-07-05 17:25 UTC (permalink / raw) To: The development of GRUB 2 [-- Attachment #1: Type: text/plain, Size: 720 bytes --] On Sat, Jul 5, 2008 at 7:01 PM, Marco Gerards <mgerards@xs4all.nl> wrote: >> + grub_printf ("HH\n"); > > Whoops? ;-) > >> + return grub_error (GRUB_ERR_NOT_IMPLEMENTED_YET, >> + "ext2fs doesn't support extents"); > > Why the error? I thought you have added extent support? Doesn't this > mean the extent has another error of some kind? Hi, Oh, I forget to cleanup the code, here is the new patch. 2008-07-06 Bean <bean123ch@gmail.com> * fs/ext2.c (EXT4_EXTENTS_FLAG): New macro. (grub_ext4_extent_header): New structure. (grub_ext4_extent): Likewise. (grub_ext4_extent_idx): Likewise. (grub_ext4_find_leaf): New function. (grub_ext2_read_block): Handle extents. -- Bean [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: extent.diff --] [-- Type: text/x-diff; name=extent.diff, Size: 3775 bytes --] diff --git a/fs/ext2.c b/fs/ext2.c index 22fd272..80e6576 100644 --- a/fs/ext2.c +++ b/fs/ext2.c @@ -86,6 +86,8 @@ #define EXT3_JOURNAL_FLAG_DELETED 4 #define EXT3_JOURNAL_FLAG_LAST_TAG 8 +#define EXT4_EXTENTS_FLAG 0x80000 + /* The ext2 superblock. */ struct grub_ext2_sblock { @@ -226,6 +228,33 @@ struct grub_ext3_journal_sblock grub_uint32_t start; }; +#define EXT4_EXT_MAGIC 0xf30a + +struct grub_ext4_extent_header +{ + grub_uint16_t magic; + grub_uint16_t entries; + grub_uint16_t max; + grub_uint16_t depth; + grub_uint32_t generation; +}; + +struct grub_ext4_extent +{ + grub_uint32_t block; + grub_uint16_t len; + grub_uint16_t start_hi; + grub_uint32_t start; +}; + +struct grub_ext4_extent_idx +{ + grub_uint32_t block; + grub_uint32_t leaf; + grub_uint16_t leaf_hi; + grub_uint16_t unused; +}; + struct grub_fshelp_node { struct grub_ext2_data *data; @@ -262,6 +291,46 @@ grub_ext2_blockgroup (struct grub_ext2_data *data, int group, sizeof (struct grub_ext2_block_group), (char *) blkgrp); } +static struct grub_ext4_extent_header * +grub_ext4_find_leaf (struct grub_ext2_data *data, + struct grub_ext4_extent_header *ext_block, + grub_uint32_t fileblock) +{ + char buf[EXT2_BLOCK_SIZE(data)]; + struct grub_ext4_extent_idx *index; + + while (1) + { + int i; + grub_disk_addr_t block; + + index = (struct grub_ext4_extent_idx *) (ext_block + 1); + + if (grub_le_to_cpu16(ext_block->magic) != EXT4_EXT_MAGIC) + return 0; + + if (ext_block->depth == 0) + return ext_block; + + for (i = 0; i < grub_le_to_cpu16 (ext_block->entries); i++) + { + if (fileblock < grub_le_to_cpu32(index[i].block)) + break; + } + + if (i == 0) + return 0; + + block = grub_le_to_cpu16 (index[i].leaf_hi); + block = (block << 32) + grub_le_to_cpu32 (index[i].leaf); + if (grub_disk_read (data->disk, + block << LOG2_EXT2_BLOCK_SIZE (data), + 0, sizeof (buf), buf)) + return 0; + + ext_block = (struct grub_ext4_extent_header *) buf; + } +} static grub_disk_addr_t grub_ext2_read_block (grub_fshelp_node_t node, grub_disk_addr_t fileblock) @@ -272,6 +341,38 @@ grub_ext2_read_block (grub_fshelp_node_t node, grub_disk_addr_t fileblock) unsigned int blksz = EXT2_BLOCK_SIZE (data); int log2_blksz = LOG2_EXT2_BLOCK_SIZE (data); + if (inode->flags & EXT4_EXTENTS_FLAG) + { + struct grub_ext4_extent_header *leaf; + struct grub_ext4_extent *ext; + int i; + + leaf = grub_ext4_find_leaf (data, + (struct grub_ext4_extent_header *) inode->blocks.dir_blocks, + fileblock); + if (! leaf) + { + grub_error (GRUB_ERR_BAD_FS, "invalid extent"); + return -1; + } + + ext = (struct grub_ext4_extent *) (leaf + 1); + for (i = 0; i < grub_le_to_cpu16 (leaf->entries); i++) + if ((fileblock >= grub_le_to_cpu32 (ext[i].block)) && + (fileblock < grub_le_to_cpu32 (ext[i].block) + + grub_le_to_cpu16 (ext[i].len)) && + ((grub_le_to_cpu16 (ext[i].len) >> 15) == 0)) + { + grub_disk_addr_t start; + + start = grub_le_to_cpu16 (ext[i].start_hi); + start = (start << 32) + grub_le_to_cpu32 (ext[i].start); + return fileblock - grub_le_to_cpu32 (ext[i].block) + start; + } + + grub_error (GRUB_ERR_BAD_FS, "something wrong with extent"); + return -1; + } /* Direct blocks. */ if (fileblock < INDIRECT_BLOCKS) blknr = grub_le_to_cpu32 (inode->blocks.dir_blocks[fileblock]); ^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: [PATCH] ext4 extent support 2008-07-04 17:59 [PATCH] ext4 extent support Bean ` (2 preceding siblings ...) 2008-07-05 11:01 ` Marco Gerards @ 2008-07-10 21:30 ` Felix Zielcke 2008-07-11 7:25 ` Bean 3 siblings, 1 reply; 21+ messages in thread From: Felix Zielcke @ 2008-07-10 21:30 UTC (permalink / raw) To: The development of GRUB 2 From: "Bean" <bean123ch@gmail.com> Sent: Friday, July 04, 2008 7:59 PM To: "The development of GRUB 2" <grub-devel@gnu.org> Subject: [PATCH] ext4 extent support > Hi, > > This patch add support for extents in ext4. > > -- > Bean > Any news? Will it be committed soon? Just saw that there's a commit on e2fsprogs 1.41 wich enables uninit_bg enables for ext4 by default. It would be very nice if grub would support that, too :) huge_file,dir_nlink,extra_isize are enabled now, too but these are ROCOMPAT features so no need to worry Tytso wants to get e2fsprogs 1.41 into lenny [1] Woudn' be that bad if grub would support ext4 on lenny [1] http://lists.debian.org/debian-release/2008/07/msg00120.html ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] ext4 extent support 2008-07-10 21:30 ` Felix Zielcke @ 2008-07-11 7:25 ` Bean 2008-07-11 7:35 ` Felix Zielcke 0 siblings, 1 reply; 21+ messages in thread From: Bean @ 2008-07-11 7:25 UTC (permalink / raw) To: The development of GRUB 2 On Fri, Jul 11, 2008 at 5:30 AM, Felix Zielcke <fzielcke@z-51.de> wrote: > From: "Bean" <bean123ch@gmail.com> > Sent: Friday, July 04, 2008 7:59 PM > To: "The development of GRUB 2" <grub-devel@gnu.org> > Subject: [PATCH] ext4 extent support > >> Hi, >> >> This patch add support for extents in ext4. >> >> -- >> Bean >> > > Any news? Will it be committed soon? > Just saw that there's a commit on e2fsprogs 1.41 wich enables uninit_bg > enables for ext4 by default. > It would be very nice if grub would support that, too :) > > huge_file,dir_nlink,extra_isize are enabled now, too but these are ROCOMPAT > features so no need to worry > > Tytso wants to get e2fsprogs 1.41 into lenny [1] > Woudn' be that bad if grub would support ext4 on lenny > > [1] http://lists.debian.org/debian-release/2008/07/msg00120.html Hi, Can you make a small test image with uninit_bg flag enabled ? -- Bean ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] ext4 extent support 2008-07-11 7:25 ` Bean @ 2008-07-11 7:35 ` Felix Zielcke 2008-07-11 8:17 ` Bean 0 siblings, 1 reply; 21+ messages in thread From: Felix Zielcke @ 2008-07-11 7:35 UTC (permalink / raw) To: The development of GRUB 2 [-- Attachment #1: Type: text/plain, Size: 403 bytes --] From: "Bean" <bean123ch@gmail.com> Sent: Friday, July 11, 2008 9:25 AM To: "The development of GRUB 2" <grub-devel@gnu.org> Subject: Re: [PATCH] ext4 extent support > Hi, > > Can you make a small test image with uninit_bg flag enabled ? > > -- > Bean Attached, i made it 30 MB big, because that's the size of the /boot I tested with but that shouldn't matter Thanks for working on it, very nice :) [-- Attachment #2: ext4.img.bz2 --] [-- Type: application/octet-stream, Size: 2271 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] ext4 extent support 2008-07-11 7:35 ` Felix Zielcke @ 2008-07-11 8:17 ` Bean 2008-07-11 8:39 ` Felix Zielcke 0 siblings, 1 reply; 21+ messages in thread From: Bean @ 2008-07-11 8:17 UTC (permalink / raw) To: The development of GRUB 2 On Fri, Jul 11, 2008 at 3:35 PM, Felix Zielcke <fzielcke@z-51.de> wrote: > From: "Bean" <bean123ch@gmail.com> > Sent: Friday, July 11, 2008 9:25 AM > To: "The development of GRUB 2" <grub-devel@gnu.org> > Subject: Re: [PATCH] ext4 extent support > >> Hi, >> >> Can you make a small test image with uninit_bg flag enabled ? >> >> -- >> Bean > > Attached, i made it 30 MB big, because that's the size of the /boot I tested > with but that shouldn't matter > Thanks for working on it, very nice :) Hi, Is the image empty ? Perhaps you can add a few files to it. Also, you can use grub-fstest to check if grub can access it, For example: grub-fstest ext4.img ls / grub-fstest ext4.img ls /boot grub-fstest ext4.img hex /boot/grub.cfg -- Bean ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] ext4 extent support 2008-07-11 8:17 ` Bean @ 2008-07-11 8:39 ` Felix Zielcke 2008-07-11 15:34 ` Bean 0 siblings, 1 reply; 21+ messages in thread From: Felix Zielcke @ 2008-07-11 8:39 UTC (permalink / raw) To: The development of GRUB 2 From: "Bean" <bean123ch@gmail.com> Sent: Friday, July 11, 2008 10:17 AM To: "The development of GRUB 2" <grub-devel@gnu.org> Subject: Re: [PATCH] ext4 extent support > Hi, > > Is the image empty ? Perhaps you can add a few files to it. Also, you > can use grub-fstest to check if grub can access it, For example: > Urm, yeah sorry, didn't think that it could be more helpful with files on it I copied now my /boot to it Seems like 1,9 MB is too big for the mailing list, message returned So i just uploaded to rapidshare http://rapidshare.com/files/128833892/ext4.img.bz2.html But if you like i'll send it to you offlist > grub-fstest ext4.img ls / > grub-fstest ext4.img ls /boot > grub-fstest ext4.img hex /boot/grub.cfg just with ext4.img it didn't worked, it complained about not using an absolute path # grub2/grub-fstest /root/ext4.img ls / lost+found/ grub/ System.map-2.6.26-rc9 config-2.6.26-rc9 vmlinuz-2.6.26-rc9 # grub2/grub-fstest /root/ext4.img ls /grub/ _linux.mod amiga.mod ascii.pff biosdisk.mod bitmap.mod cdboot.img [...] vbeinfo.mod video.mod # grub2/grub-fstest /root/ext4.img hex /grub/grub.cfg 00000000 23 0a 23 20 44 4f 20 4e 4f 54 20 45 44 49 54 20 |#.# DO NOT EDIT | 00000010 54 48 49 53 20 46 49 4c 45 0a 23 0a 23 20 49 74 |THIS FILE.#.# It| 00000020 20 69 73 20 61 75 74 6f 6d 61 74 69 63 61 6c 6c | is automaticall| [...] 00000470 44 20 2f 65 74 63 2f 67 72 75 62 2e 64 2f 33 30 |D /etc/grub.d/30| 00000480 5f 6f 73 2d 70 72 6f 62 65 72 20 23 23 23 0a |_os-prober ###.| # grub2/grub-fstest /root/ext4.img hex /vmlinuz-2.6.26-rc9 grub-fstest: error: read error at offset 0. # grub2/grub-fstest /root/ext4.img ls /vmlinuz-2.6.26-rc9 vmlinuz-2.6.26-rc9 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] ext4 extent support 2008-07-11 8:39 ` Felix Zielcke @ 2008-07-11 15:34 ` Bean 2008-07-11 17:11 ` Felix Zielcke 0 siblings, 1 reply; 21+ messages in thread From: Bean @ 2008-07-11 15:34 UTC (permalink / raw) To: The development of GRUB 2 [-- Attachment #1: Type: text/plain, Size: 1909 bytes --] On Fri, Jul 11, 2008 at 4:39 PM, Felix Zielcke <fzielcke@z-51.de> wrote: > From: "Bean" <bean123ch@gmail.com> > Sent: Friday, July 11, 2008 10:17 AM > To: "The development of GRUB 2" <grub-devel@gnu.org> > Subject: Re: [PATCH] ext4 extent support > >> Hi, >> >> Is the image empty ? Perhaps you can add a few files to it. Also, you >> can use grub-fstest to check if grub can access it, For example: >> > > Urm, yeah sorry, didn't think that it could be more helpful with files on it > I copied now my /boot to it > Seems like 1,9 MB is too big for the mailing list, message returned > So i just uploaded to rapidshare > > http://rapidshare.com/files/128833892/ext4.img.bz2.html > > But if you like i'll send it to you offlist > >> grub-fstest ext4.img ls / >> grub-fstest ext4.img ls /boot >> grub-fstest ext4.img hex /boot/grub.cfg > > just with ext4.img it didn't worked, it complained about not using an > absolute path > > # grub2/grub-fstest /root/ext4.img ls / > lost+found/ grub/ System.map-2.6.26-rc9 config-2.6.26-rc9 vmlinuz-2.6.26-rc9 > # grub2/grub-fstest /root/ext4.img ls /grub/ > _linux.mod amiga.mod ascii.pff biosdisk.mod bitmap.mod cdboot.img [...] > vbeinfo.mod video.mod > # grub2/grub-fstest /root/ext4.img hex /grub/grub.cfg > 00000000 23 0a 23 20 44 4f 20 4e 4f 54 20 45 44 49 54 20 |#.# DO NOT EDIT > | > 00000010 54 48 49 53 20 46 49 4c 45 0a 23 0a 23 20 49 74 |THIS FILE.#.# > It| > 00000020 20 69 73 20 61 75 74 6f 6d 61 74 69 63 61 6c 6c | is > automaticall| > [...] > 00000470 44 20 2f 65 74 63 2f 67 72 75 62 2e 64 2f 33 30 |D > /etc/grub.d/30| > 00000480 5f 6f 73 2d 70 72 6f 62 65 72 20 23 23 23 0a |_os-prober > ###.| > # grub2/grub-fstest /root/ext4.img hex /vmlinuz-2.6.26-rc9 > grub-fstest: error: read error at offset 0. > # grub2/grub-fstest /root/ext4.img ls /vmlinuz-2.6.26-rc9 > vmlinuz-2.6.26-rc9 Hi, This patch should fix the problem. -- Bean [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: extent_2.diff --] [-- Type: text/x-diff; name=extent_2.diff, Size: 3897 bytes --] diff --git a/fs/ext2.c b/fs/ext2.c index 22fd272..d8e1b3e 100644 --- a/fs/ext2.c +++ b/fs/ext2.c @@ -86,6 +86,8 @@ #define EXT3_JOURNAL_FLAG_DELETED 4 #define EXT3_JOURNAL_FLAG_LAST_TAG 8 +#define EXT4_EXTENTS_FLAG 0x80000 + /* The ext2 superblock. */ struct grub_ext2_sblock { @@ -226,6 +228,33 @@ struct grub_ext3_journal_sblock grub_uint32_t start; }; +#define EXT4_EXT_MAGIC 0xf30a + +struct grub_ext4_extent_header +{ + grub_uint16_t magic; + grub_uint16_t entries; + grub_uint16_t max; + grub_uint16_t depth; + grub_uint32_t generation; +}; + +struct grub_ext4_extent +{ + grub_uint32_t block; + grub_uint16_t len; + grub_uint16_t start_hi; + grub_uint32_t start; +}; + +struct grub_ext4_extent_idx +{ + grub_uint32_t block; + grub_uint32_t leaf; + grub_uint16_t leaf_hi; + grub_uint16_t unused; +}; + struct grub_fshelp_node { struct grub_ext2_data *data; @@ -262,6 +291,45 @@ grub_ext2_blockgroup (struct grub_ext2_data *data, int group, sizeof (struct grub_ext2_block_group), (char *) blkgrp); } +static struct grub_ext4_extent_header * +grub_ext4_find_leaf (struct grub_ext2_data *data, char *buf, + struct grub_ext4_extent_header *ext_block, + grub_uint32_t fileblock) +{ + struct grub_ext4_extent_idx *index; + + while (1) + { + int i; + grub_disk_addr_t block; + + index = (struct grub_ext4_extent_idx *) (ext_block + 1); + + if (grub_le_to_cpu16(ext_block->magic) != EXT4_EXT_MAGIC) + return 0; + + if (ext_block->depth == 0) + return ext_block; + + for (i = 0; i < grub_le_to_cpu16 (ext_block->entries); i++) + { + if (fileblock < grub_le_to_cpu32(index[i].block)) + break; + } + + if (--i < 0) + return 0; + + block = grub_le_to_cpu16 (index[i].leaf_hi); + block = (block << 32) + grub_le_to_cpu32 (index[i].leaf); + if (grub_disk_read (data->disk, + block << LOG2_EXT2_BLOCK_SIZE (data), + 0, EXT2_BLOCK_SIZE(data), buf)) + return 0; + + ext_block = (struct grub_ext4_extent_header *) buf; + } +} static grub_disk_addr_t grub_ext2_read_block (grub_fshelp_node_t node, grub_disk_addr_t fileblock) @@ -272,6 +340,50 @@ grub_ext2_read_block (grub_fshelp_node_t node, grub_disk_addr_t fileblock) unsigned int blksz = EXT2_BLOCK_SIZE (data); int log2_blksz = LOG2_EXT2_BLOCK_SIZE (data); + if (inode->flags & EXT4_EXTENTS_FLAG) + { + char buf[EXT2_BLOCK_SIZE(data)]; + struct grub_ext4_extent_header *leaf; + struct grub_ext4_extent *ext; + int i; + + leaf = grub_ext4_find_leaf (data, buf, + (struct grub_ext4_extent_header *) inode->blocks.dir_blocks, + fileblock); + if (! leaf) + { + grub_error (GRUB_ERR_BAD_FS, "invalid extent"); + return -1; + } + + ext = (struct grub_ext4_extent *) (leaf + 1); + for (i = 0; i < grub_le_to_cpu16 (leaf->entries); i++) + { + if (fileblock < grub_le_to_cpu32 (ext[i].block)) + break; + } + + if (--i >= 0) + { + fileblock -= grub_le_to_cpu32 (ext[i].block); + if (fileblock >= grub_le_to_cpu16 (ext[i].len)) + return 0; + else + { + grub_disk_addr_t start; + + start = grub_le_to_cpu16 (ext[i].start_hi); + start = (start << 32) + grub_le_to_cpu32 (ext[i].start); + + return fileblock + start; + } + } + else + { + grub_error (GRUB_ERR_BAD_FS, "something wrong with extent"); + return -1; + } + } /* Direct blocks. */ if (fileblock < INDIRECT_BLOCKS) blknr = grub_le_to_cpu32 (inode->blocks.dir_blocks[fileblock]); ^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: [PATCH] ext4 extent support 2008-07-11 15:34 ` Bean @ 2008-07-11 17:11 ` Felix Zielcke 2008-07-11 17:42 ` Bean 0 siblings, 1 reply; 21+ messages in thread From: Felix Zielcke @ 2008-07-11 17:11 UTC (permalink / raw) To: The development of GRUB 2 From: "Bean" <bean123ch@gmail.com> Sent: Friday, July 11, 2008 5:34 PM > Hi, > > This patch should fix the problem. > > -- > Bean > Hello, yeah, it works fine now. Thanks very much ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] ext4 extent support 2008-07-11 17:11 ` Felix Zielcke @ 2008-07-11 17:42 ` Bean 2008-07-13 1:17 ` Bean 0 siblings, 1 reply; 21+ messages in thread From: Bean @ 2008-07-11 17:42 UTC (permalink / raw) To: The development of GRUB 2 On Sat, Jul 12, 2008 at 1:11 AM, Felix Zielcke <fzielcke@z-51.de> wrote: > From: "Bean" <bean123ch@gmail.com> > Sent: Friday, July 11, 2008 5:34 PM >> >> Hi, >> >> This patch should fix the problem. >> >> -- >> Bean >> > > > Hello, > > yeah, it works fine now. > Thanks very much Hi, Thanks for your testing, if there is no objection, I'd commit it soon. -- Bean ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] ext4 extent support 2008-07-11 17:42 ` Bean @ 2008-07-13 1:17 ` Bean 0 siblings, 0 replies; 21+ messages in thread From: Bean @ 2008-07-13 1:17 UTC (permalink / raw) To: The development of GRUB 2 On Sat, Jul 12, 2008 at 1:42 AM, Bean <bean123ch@gmail.com> wrote: > On Sat, Jul 12, 2008 at 1:11 AM, Felix Zielcke <fzielcke@z-51.de> wrote: >> From: "Bean" <bean123ch@gmail.com> >> Sent: Friday, July 11, 2008 5:34 PM >>> >>> Hi, >>> >>> This patch should fix the problem. >>> >>> -- >>> Bean >>> >> >> >> Hello, >> >> yeah, it works fine now. >> Thanks very much > > Hi, > > Thanks for your testing, if there is no objection, I'd commit it soon. Committed. -- Bean ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2008-07-13 1:17 UTC | newest] Thread overview: 21+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-07-04 17:59 [PATCH] ext4 extent support Bean 2008-07-04 18:39 ` Robert Millan 2008-07-04 18:47 ` Bean 2008-07-05 9:39 ` Felix Zielcke 2008-07-05 13:25 ` Javier Martín 2008-07-05 17:15 ` Felix Zielcke 2008-07-05 18:09 ` Javier Martín 2008-07-06 4:51 ` Bean 2008-07-06 13:12 ` Felix Zielcke 2008-07-06 8:44 ` Felix Zielcke 2008-07-05 11:01 ` Marco Gerards 2008-07-05 17:25 ` Bean 2008-07-10 21:30 ` Felix Zielcke 2008-07-11 7:25 ` Bean 2008-07-11 7:35 ` Felix Zielcke 2008-07-11 8:17 ` Bean 2008-07-11 8:39 ` Felix Zielcke 2008-07-11 15:34 ` Bean 2008-07-11 17:11 ` Felix Zielcke 2008-07-11 17:42 ` Bean 2008-07-13 1:17 ` Bean
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.