[linux-lvm] lvm-0.6, Linux 2.2.9

[Heinz Mauelshagen]

> 
> Rolf writes:
> > thanks for the link. Maybe we should bring the code to the author of
> > ext2resize. A combination of both approaches may be what we are (or at
> > least I am) looking for.
> 
> I had a closer look at the ext2-volume code today.  There are two parts -
> 1) a program (e2extend) to take a newly mke2fs'd device and increment the
>    inode block numbers and the group descriptor block counts in the new
>    device by the number of blocks in the original fs.
> 2) a kernel patch to ext2 code which will handle the fact that we need to
>    look at multiple devices when accessing different parts of the fs.  One
>    interesting thing is that it never modifies the original fs data, only
>    the in-kernel representation by totalling the blocks, groups, inodes
>    as each extension filesystem is mounted...  It may do something in
>    addition to this but I couldn't see it.
> 
> What I don't understand (since I haven't really looked at ext2 internals
> before), is what is different about the above scheme compared to running
> "mke2fs -S" on the LVM-enlarged LV?  According to Theodore, the "mke2fs -S"
> method will corrupt the fs if it is enlarged past a 250MB? boundary because
> an ext2 sturcture (superblock?, bitmap?, anyone know?) will grow and
> overwrite other data on the filesystem.

It's the block group descriptor table (GDT).

A block group descriptor is a structure 32 bytes in size to describe
the location of block bitmap, inode bitmaps, inode tables and so on
(see /usr/src/linux/include/linux/ext2_fs.h;
 definition of struct ext2_group_desc)

If you have a regular block size of 1k, 32 of these fit into one block.
Groups have a size of 8m --> 8M times 32 = 256M.
IOW: "ext2fs size in megabyte module 256m + 1" equals the amount of
     block group descriptor blocks at mke2fs time.

So...

If you want to resize an ext2fs which is smaller than 256M to a size > 256M
you have to play around remapping the structures which follow the group
descriptor block like inodes etc.
Same remapping stuff takes place with n * 256M (n=1 to verybig 8*) )
resizing start sizes.

> 
> I haven't yet looked at ext2resize to see what it does to overcome this
> issue,

AFAI saw it does remapping.

> and I don't know enough about ext2 to know what it is myself.
> Otherwise, 90% of the ext2-volume patch to the kernel can be discarded
> because LVM makes the enlarged LV appear to be a single device to the
> kernel, and "all" we need to do is have mke2fs create only the ext2
> structures on the newly extended part of the LV, and then go back to
> the ext2 superblock(s) to update the data there.  According to
> ext_update_summary() in the ext2-multi-device.diff we would need to update:
> blocks_count, free_blocks_count, r_blocks_count, free_inodes_count,
> inodes_count, groups_count
> in the superblock, and then remount the filesystem.  There are no doubt
> issues about flushing in-kernel fs metadata to disk before we update the
> on-disk structures.  It may be better to update the in-kernel metadata
> like the ext2-volume patch does, and then when the filesystem is unmounted
> (or remounted?) it will update the data on disk, or we could force a flush
> to disk somehow.
> 

Good ideas.

More people out there to dig into this?


Regards,
Heinz

--

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Systemmanagement C/S                             Deutsche Telekom AG
                                                 Entwicklungszentrum Darmstadt
Heinz Mauelshagen                                Otto-Roehm-Strasse 71c
Senior Systems Engineer                          Postfach 10 05 41
                                                 64205 Darmstadt
mge at ez-darmstadt.telekom.de                      Germany
                                                 +49 6151 886-425
                                                          FAX-386
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-