Subject: Re: resize_ffs (was: Re: JFS)
To: David Laight <firstname.lastname@example.org>
From: Bill Studenmund <email@example.com>
Date: 02/27/2003 08:56:43
On Wed, 26 Feb 2003, David Laight wrote:
> > I think how AIX does it is they tune the file system parameters so that
> > the cylinder group size is the same as the PP size (Physical Partition, LV
> > allocation unit, 4 MB on the boxes I ran). That way growing is just adding
> > a whole cylinder group.
> That shouldn't be necessary - aren't the blocks in the last cylinder
> group just marked 'allocated' - so once there is physical space
> backing them they can freed (so they can be allocated to files).
While it might not be "necessary", it sure would make life easier. And
it's what I think we should do when we have an LVM.
With AIX's LVM, it doesn't really make sense to worry about real on-disk
cylinders. Among other things, you can have logical volumes mirrored or
striped on vastly different physical disks. In that case, there is no one
underlying geometry, so you might as well make up something convenient.
Also, AIX's LVM (and most I believe) can grow logical volumes one PP at a
time. This means you can get an LV that consists of fragmented, non
adjacent PPs. ffs assumes that items in a cylinder group are near-by. If
we let a cg cross a PP boundary, a sub-optimal case (fragmentation) could
rapidly turn into a craptacular case with the fragmentation in the middle
of a cg. :-(
So an integer number of cg/PP is the nicest way to go, and there's no real
need for more than 1 cg/PP.
Thirdly, with cgs sized to match PPs, you get a constant amount of
metadata per PP. :-)