Re: [linux-lvm] lvm-0.6, Linux 2.2.9

Re: [linux-lvm] lvm-0.6, Linux 2.2.9

[Rolf Jakob]

> I had also found an old utility (extend2fs v0.1) at tsx-11.mit.edu
> (I think) which claimed to allow resizing of ext2 filesystems
> dynamically by concatenating disks.  Since you could consider this
> conceptually the same as adding LEs to the end of a LV, it may be
> possible to modify the code to work with LVM.  The code was originally
> written by Miguel de Icaza, but when I contacted him, he was too
> busy working on other projects (GNOME I think) to work on this anymore.
> If anyone is interested in this code, I can send it to them or put
> it on my web site, as it appears that tsx-11 is not currently
> available.

Yes, that is very interesting. Ext2fs has been there for quite a long time,
so chances are good that it still works. I would like to take a look at it.

Could you please send it to me or mail the URL where you put it ?

Rolf
-- 
Rolf Jakob at home (rjakob@duffy1.franken.de)
WWW : http://www.franken.de/users/duffy1/rjakob (KDE-Utils and CCS)

Re: [linux-lvm] lvm-0.6, Linux 2.2.9

[Andreas Dilger]

Rolf writes:
> Yes, that is very interesting. Ext2fs has been there for quite a long time,
> so chances are good that it still works. I would like to take a look at it.
>
> Could you please send it to me or mail the URL where you put it ?

I have uploaded the old ext2-volume-v0.1.tar.gz to my web site,
http://www-mddsp.enel.ucalgary.ca/People/adilger/ext2-volume-v0.1.tar.gz

as I couldn't connect to tsx-11 lately, which is where I found it originally.
The good news is that the patch was developed for 2.1.42, so it is at least
half-way to working with 2.2.

I had another quick look at the README/code, and it looks like LVM will
help with some of the basic problems mentioned therein, such as handling
multiple disk names, changing e2fsck, changing the mount command.  All
of those problems go away because we are growing an LV, rather than
concatenating volumes.  The one trick will be to build the basic ext2
stuctures on the extended part of the LV without touching the current
filesystem - this may require modifications to mke2fs.  Another good thing
is that this definitely claims to work with a mounted filesystem, although
it requires a remount a-la "mount -o remount,rw...", but I think this will
work on an FS that has open files on it.

One note is that the original author, Miguel de Icaza, is no longer supporting
this code (he's busy working on GNOME), so don't bug him about it.

Cheers, Andreas
-- 
Andreas Dilger   University of Calgary  \"If a man ate a pound of pasta and
                 Micronet Research Group \ a pound of antipasto, would they
Dept of Electrical & Computer Engineering \   cancel out, leaving him still
http://www-mddsp.enel.ucalgary.ca/People/adilger/       hungry?" -- Dogbert

Re: [linux-lvm] lvm-0.6, Linux 2.2.9

[Rolf Jakob]

Hi,

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.

> filesystem - this may require modifications to mke2fs.  Another good thing
> is that this definitely claims to work with a mounted filesystem, although
> it requires a remount a-la "mount -o remount,rw...", but I think this will
> work on an FS that has open files on it.

Ah, that's it. I feel a resizable file system approaching ... ;-)

Rolf
-- 
Rolf Jakob at home (rjakob@duffy1.franken.de)
WWW : http://www.franken.de/users/duffy1/rjakob (KDE-Utils and CCS)

Re: [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@ez-darmstadt.telekom.de                      Germany
                                                 +49 6151 886-425
                                                          FAX-386
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-lvm] lvm-0.6, Linux 2.2.9

[Andreas Dilger]

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.

I haven't yet looked at ext2resize to see what it does to overcome this
issue, 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.

Cheers, Andreas
-- 
Andreas Dilger  University of Calgary \ "If a man ate a pound of pasta and
                Micronet Research Group \ a pound of antipasto, would they
Dept of Electrical & Computer Engineering \  cancel out, leaving him still
http://www-mddsp.enel.ucalgary.ca/People/adilger/      hungry?" -- Dogbert