Hi,

I have come across an error when increasing a large filesystem:

# df -k /app/cpsd010/05
Filesystem 1024-blocks Free %Used Iused %Iused Mounted on
/dev/cpsd010_05 268435456 41024068 85% 95 1% /app/cpsd010/05

# chfs -a size=+51200M /app/cpsd010/05
chfs: 0506-932 Can not extend a JFS file system with nbpi = 16384
and frag = 4096 past 536870912 (512 byte blocks).

the filesystem is at its limit due to the nbpi setting.

can someone advise as I am sure that I cannot just increase this setting as it will corrupt the filesystem?

If that is the case does someone have a better procedure than:

1> create another vg / lv / fs on a seperate lun that will allow the fs to be increased to its maximum size.

2> stop the application and copy / migrate the data to the new fs

3> remove the old VG structure and rename the new VG structure.

any help is greatly appreciated.

Thanks

Chris

The nbpi (number of bytes per inode) setting is FS-specific, you do not have to create a new VG for that.

Create a new FS, whereever you want, but preferably in the same VG. Select "JFS2" (preferably) or "JFS" as the LV-type.

mklv -y<LV-name> -tjfs2 <vgname> <nr_of_LPs>
or (less preferable)
mklv -y<LV-name> -tjfs <vgname> <nr_of_LPs>

Create a FS on this LV of the type you opted for

crfs -v jfs2 -d<LV_name> -m<mountpoint> -A<yes/no> -a agblksize=4096 -a logname=<log_volume/INLINE>
or (jfs-style)
crfs -v jfs -d<LV_name> -m<mountpoint> -A<yes/no> -a nbpi=<nbpi-value> -a ag=64

You may want to edit the /etc/filesystems to include the new FS in a mountgroup.

After mounting the FS in a parallel dir, copy all the files while the app is still running:

cd <olddir> ; tar -cvf - | (cd <newdir> ; tar -xf -)

Then stop the application, copy the files which were open (tar will complain about them) again, umount the old FS, mount the new one and restart the app.

Downtime should be some minutes.

bakunin

ok magic!

Thanks.

Chris.