[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