[linux-lvm] Alpha testers rqd for ext2 fs extend utility.

[linux-lvm] Alpha testers rqd for ext2 fs extend utility.

[Mike Field]

I'm a HP-UX user and love LVM. I find the lack of an free extendfs
utility a real hole in LVM on Linux - so I've done something about it!

I've finially hacked togeather to version 0.1.0 of ext2end - my ext2
file system extend utlity. It has two limitations at present:

1. It cannot extend a file further than the limit of the group
descriptor table (in practice over 256M boundary for 1024 byte blocks).
So a 257Mb file system can be extended to a 512 MB file system,  but a
255M Bone can't be extended to 257MB. This will be fixed as soon as I
learn enough about inodes to do some inode relocation, allowing the
group descriptor table to be extended without moving all the data.

2. Because I am using lseek() the maximum file system size that I would
be confident running it on is 2GB (but it might run upto 4GB... maybe).
If anybody knows how to do block oriented file IO under linux can they
drop me a email. Otherwise I'll have to troll the glib sources...

A minor issue is that the number of nodes is fixed to the number of
inodes/per group as  the original file system (to avoid moving data
around): if you need more Inodes you have to extend a lot - maybe upto
8MB to open a new group...

Apart from that it works, but it is early, early alpha.  I'm looking for
some alpha testers to send my source tarballs to.  Please don't sign up
unless you have a tape drive :-)

Also, don't expect too much - command line options (like disabling the
pre/post-extend fscks) and header comments in source files are on the
list for for version 0.1.1, and debuging switches are changed in a
source file (for 0.1.1 also). Hell, it might even allow you to attempt
to extend mounted file systems (can you say 'kernel panic'?). This
project will officially put under the GPL, but at the moment I'ld rather
fix limitations 1&2 that worry about paperwork.

So till version 0.2.0, if you want it, send a mail, I'll send you the
source.

Mike Field

PS. Anybody got any spare web space to host the source????

Re: [linux-lvm] Alpha testers rqd for ext2 fs extend utility.

[Andreas Dilger]

Mike Field writes:
> I'm a HP-UX user and love LVM. I find the lack of an free extendfs
> utility a real hole in LVM on Linux - so I've done something about it!

Just in case you hadn't seen the discussion lately here and on
linux-fsdevel mailing list, Lennert Buytenhek is also working on a GPL
ext2 extender.  It apparently will handle the 256MB limit by moving
data blocks around during the resize as well.  I don't have the URL
handy, but it was posted in the linux-lvm mailing list in the last
week.

One thing I was thinking is if we can't make the ext2 resize work past
the 256MB boundary while the filesystem is mounted, we could have the
existing "ext2-resize" program do the resizing while unmounted, but
also have a different utility (or a separate function of ext2-resize)
that will allow growth to the next 256MB boundary while the FS is
mounted, for those emergency times when you just need a bit more
space and can't afford a shutdown...

Another possibility (if the ext2 kernel code can handle it) is to build
the ext2 filesystem "pre-enlarged" with enough group descriptors and
inode blocks for a much larger filesystem, and then we don't have the 
issue of moving blocks around on a (un)mounted filesystem.  I think that
this is what AIX does, since when you create a new JFS filesystem (selecting
bytes/inode and cluster size) it replies with:

Based on the parameters chosen, the new /tt JFS file system
is limited to a maximum size of 134217728 (512 byte blocks)

so there is a pre-determined JFS size limit as well, it's just a very
large one.  That would be the equivalent of ext2's 256MB resize limit,
and AIX JFS doesn't allow you to expand past the size which is determined
at JFS creation time.

I know that there are calculations in the kernel, and in the ext2 tools
which work out GD size and inode block counts based on the total number
of blocks, but would it be possible to somehow dissociate these two numbers,
and say we will have X group descriptors, and Y inode blocks no matter
how big the FS currently is?  Then all we have to do is pick X and Y large
enough to satisfy most expansion limits, maybe 128x as large as the original
filesystem size.

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] Alpha testers rqd for ext2 fs extend utility.

[Peter Wuestefeld]

Hi Andreas,

sorry, but I have to comment on this:

> Another possibility (if the ext2 kernel code can handle it) is to build
> the ext2 filesystem "pre-enlarged" with enough group descriptors and
> inode blocks for a much larger filesystem, and then we don't have the
> issue of moving blocks around on a (un)mounted filesystem.  I think that
> this is what AIX does, since when you create a new JFS filesystem (selecting
> bytes/inode and cluster size) it replies with:

> Based on the parameters chosen, the new /tt JFS file system
> is limited to a maximum size of 134217728 (512 byte blocks)

> so there is a pre-determined JFS size limit as well, it's just a very
> large one.  That would be the equivalent of ext2's 256MB resize limit,
> and AIX JFS doesn't allow you to expand past the size which is determined
> at JFS creation time.

What you see there is not related to the "newly created" JFS. It is the effect
of a parameter set on the LV - in smitty the "MAXIMUM NUMBER of LOGICAL
PARTITIONS" when you create an new LV (on the command line, it is the "-x"
parameter to mklv). This parameter can be changed later and is only a soft stop,
preventing you from accidentially creating LVs too large. AIX allocates place
for structures (inodes, superblocks) in a filesystem in 8MB chunks (by default
if you are using 4MB PEs), known as Allocation Group size. This means that if
you extend a LV by, say, 4MB, the place for holding inodes for 2*4MB is
allocated in that group. Extendig that FS by another 4MB would then not lead to
additional allocation of space for structures in this Allocation Group.

So this leads to the idea that, instead of allocate already space in the
filesystem for holding all structures of a 256M FS when creating a FS even
smaller, to allocate that in  steps say, related to the PE/LE size of that VG.
By that we would gain even more flexibility I think.

Just my 2P worth ...

Greetings,

Peter

Mit freundlichem Gruss/Best Regards

Peter Wuestefeld
IBM Certified Support Professional AIX 4.3
==================================
res nova Unternehmensberatung GmbH
                   ...aktiv in AIX
MAIL:  Ruppmannstrasse 41
       D-70565 Stuttgart, Germany
FON:   +49 711 78888 0
FAX:   +49 711 78888 99
WWW:   http://www.resnova.de
SMTP: mailto: Peter.Wuestefeld@resnova.de

The idea that an arbitrary naive human should be able to properly use a given
tool without training or understanding is even more wrong for computing than
it is for other tools (e.g. automobiles, airplanes, guns, power saws).
                -- Doug Gwyn

Re: [linux-lvm] Alpha testers rqd for ext2 fs extend utility.

[Andreas Dilger]

I wrote:
> > Based on the parameters chosen, the new /tt JFS file system
> > is limited to a maximum size of 134217728 (512 byte blocks)

Doug replied:
> What you see there is not related to the "newly created" JFS. It is the effect
> of a parameter set on the LV - in smitty the "MAXIMUM NUMBER of LOGICAL
> PARTITIONS" when you create an new LV (on the command line, it is the "-x"
> parameter to mklv).

Actually, the above number was from an AIX 4.1.5 system, and it corresponds
to a 64GB filesystem, which is the largest that AIX can handle at that level.
I know about the parameter you refer to, but the default is 512 LPs at 4MB
PP size, which is only a 2GB filesystem by default.  There IS A LIMIT on
how much an AIX JFS filesystem can grow based on the original parameters.

> So this leads to the idea that, instead of allocate already space in the
> filesystem for holding all structures of a 256M FS when creating a FS even
> smaller, to allocate that in  steps say, related to the PE/LE size of that VG.
> By that we would gain even more flexibility I think.

The current setup of ext2 has 2 different size boundaries - 8MB groups,
and for each 32 groups (256MB) you need another 1K block at the head of each
group to hold another group descriptor (I think).

I have been emailing with Mike Field about this, and he has the same
idea that I do - to "pre-reserve" blocks at the head of each group in a
new ext2 FS, by either allocating them to a file (maybe a
.../lost+found/.ext2reserved file - kind of klugy though), or somehow
marking them used in the bad-blocks bitmap, so that later expansion of
the FS does not need to move data blocks around.  When we need to
increase the number of group descriptor blocks when the FS is enlarged,
we simply write the correct data into the pre-allocated block, lock the
FS in the kernel for a microsecond, update the kernel structures to
make the FS larger (and hence use the pre-allocated blocks), and free
the FS lock.  As much of the ext2 configuration as possible could be
done in user space (ie creating groups, inode bitmaps in "reserved"
blocks, etc) and only the minimum while the kernel has the filesystem
locked.  Hopefully it is possible to do all of the on-disk work outside
the kernel so we are not faced with long delays or many blocked
processes because of a long lock on the FS.

The number of blocks reserved could be based on the LVM parameters, but
LVM isn't the only way to grow a filesystem - md and hardware RAID come
to mind.  It should also be possible to reserve more blocks in an
unmounted ext2 filesystem with a tool that can do FS reorganization.
If we want a reliable online resize utility, we should make as few
changes as possible to the running filesystem, so this is why we
pre-reserve blocks.  Even with the current ext2 setup, it would be
possible to grow an ext2 filesystem to the next 256MB boundary without
any FS block moves.

What needs to be explored is how to safely make the kernel aware of the
new space while the filesystem is mounted...

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] Alpha testers rqd for ext2 fs extend utility.

[guruju]

Andreas Dilger wrote:
> 
> I wrote:
> > > Based on the parameters chosen, the new /tt JFS file system
> > > is limited to a maximum size of 134217728 (512 byte blocks)
> 
> Doug replied:
> > What you see there is not related to the "newly created" JFS. It is the effect
> > of a parameter set on the LV - in smitty the "MAXIMUM NUMBER of LOGICAL
> > PARTITIONS" when you create an new LV (on the command line, it is the "-x"
> > parameter to mklv).
> 
> Actually, the above number was from an AIX 4.1.5 system, and it corresponds
> to a 64GB filesystem, which is the largest that AIX can handle at that level.
> I know about the parameter you refer to, but the default is 512 LPs at 4MB
> PP size, which is only a 2GB filesystem by default.  There IS A LIMIT on
> how much an AIX JFS filesystem can grow based on the original parameters.
> 
> > So this leads to the idea that, instead of allocate already space in the
> > filesystem for holding all structures of a 256M FS when creating a FS even
> > smaller, to allocate that in  steps say, related to the PE/LE size of that VG.
> > By that we would gain even more flexibility I think.
> 
> The current setup of ext2 has 2 different size boundaries - 8MB groups,
> and for each 32 groups (256MB) you need another 1K block at the head of each
> group to hold another group descriptor (I think).
> 
> I have been emailing with Mike Field about this, and he has the same
> idea that I do - to "pre-reserve" blocks at the head of each group in a
> new ext2 FS, by either allocating them to a file (maybe a
> .../lost+found/.ext2reserved file - kind of klugy though), or somehow
> marking them used in the bad-blocks bitmap, so that later expansion of
> the FS does not need to move data blocks around.  When we need to
> increase the number of group descriptor blocks when the FS is enlarged,
> we simply write the correct data into the pre-allocated block, lock the
> FS in the kernel for a microsecond, update the kernel structures to
> make the FS larger (and hence use the pre-allocated blocks), and free
> the FS lock.  As much of the ext2 configuration as possible could be
> done in user space (ie creating groups, inode bitmaps in "reserved"
> blocks, etc) and only the minimum while the kernel has the filesystem
> locked.  Hopefully it is possible to do all of the on-disk work outside
> the kernel so we are not faced with long delays or many blocked
> processes because of a long lock on the FS.
> 
> The number of blocks reserved could be based on the LVM parameters, but
> LVM isn't the only way to grow a filesystem - md and hardware RAID come
> to mind.  It should also be possible to reserve more blocks in an
> unmounted ext2 filesystem with a tool that can do FS reorganization.
> If we want a reliable online resize utility, we should make as few
> changes as possible to the running filesystem, so this is why we
> pre-reserve blocks.  Even with the current ext2 setup, it would be
> possible to grow an ext2 filesystem to the next 256MB boundary without
> any FS block moves.
> 
> What needs to be explored is how to safely make the kernel aware of the
> new space while the filesystem is mounted...
> 
> 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

There is no limit in sun solaris 2.7, the file system can be more than 
2gigs. This is one of the nice features in solaris2.7

Guruju

Re: [linux-lvm] Alpha testers rqd for ext2 fs extend utility.

[Andreas Dilger]

You write:
> There is no limit in sun solaris 2.7, the file system can be more than 
> 2gigs. This is one of the nice features in solaris2.7

You misunderstood my posting.  For AIX 4.1.5, the hard FS limit is 64GB,
and for AIX 4.3 it is 256GB or something like that.  The 2GB limit I
mentioned is a "soft" limit which is set for a FS which starts life at
less than 2GB, otherwise the soft limit = current FS size.

Because it is so easy to grow AIX filesystems, and you do it on a
regular basis on running systems, there is a "safety" built in which you
have to override when growing a FS past this size, so you don't
accidentally grow a 160MB filesystem to 16GB instead of 1.6GB and use up
all of the space on your disks.  It is easy to grow a filesystem, but
lots of work to shrink it (ie backup, rebuild, restore).

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] Alpha testers rqd for ext2 fs extend utility.

[Stefan Monnier]

>>>>> "Andreas" == Andreas Dilger <adilger@enel.ucalgary.ca> writes:
> all of the space on your disks.  It is easy to grow a filesystem, but
> lots of work to shrink it (ie backup, rebuild, restore).

That's exactly why I don't like this pre-allocation idea.
It will end up with a grow2fs utility and no way to shrink a filesystem.
I'd rather see the work be out in a real ext2resize that can both grow and
shrink a filesystem, as can AdvFS.
Problem is:  shrinking will necessarily mean heavy disk reorganization
(most importantly: some files will have to be reassigned to other inodes
which means `stale filehandle' across NFS).  So I must admit that it is indeed
desirable to at least try to avoid moving things around when possible,
via (f.ex.) pre-allocation.

All in all, it just goes to show that a static inode->block mapping
as is used in ext2 (and ufs) is not flexible enough.


	Stefan