extend filesystem problems 1

[Mag0007]

I am trying to extend a filesystem via smitty, and I keep getting these errors

0516-787 extendlv: Maximum allocation for logical volume backuplv is 540.



VOLUME GROUP: vg VG IDENTIFIER: 00053f8f792f6cfc
VG STATE: active PP SIZE: 64 megabyte(s)
VG PERMISSION: read/write TOTAL PPs: 1633 (104512 megabytes)
MAX LVs: 256 FREE PPs: 1092 (69888 megabytes)
LVs: 2 USED PPs: 541 (34624 megabytes)
OPEN LVs: 2 QUORUM: 2
TOTAL PVs: 1 VG DESCRIPTORS: 2
STALE PVs: 0 STALE PPs: 0
ACTIVE PVs: 1 AUTO ON: yes
MAX PPs per PV: 2032 MAX PVs: 16

 

[p5wizard]

You need to up that maximum

use smitty chlv

or command line

chlv -x 600 backuplv

would allow your lv to grow up to 600x64MB

HTH,

p5wizard

 

[Mag0007]

now my filesystem is complaining about nbpi...

anyway to fix that now?

 

[p5wizard]

you mean other than creating a new fs and moving all the data to the new one? Can't help you there. Once the FS is created with certain values (a.o. nbpi), it sets a max FS size limit that it can't grow beyond.

you might try a lower increment?

HTH,

p5wizard

 

[Mag0007]

p5wizard:

I think I know what you are saying...Thanks asusual

The good thing is I do have an option to recreate this filesystem, but does it hurt if I select a higher value for my "Number of bytes per inode"? Currently as you know is 4096. I am thinking of 65536

What do you think?

 

[p5wizard]

Not that I'm aware of, but you might also want to check if you can create the filesystem as JFS2 if your AIX is recent enough. Less hassle/overhead with very large filesystems.

If you create a JFS filesystem, then with the values you specify (or defaults) for nbpi, frag and ag, you set a max FS-size that you can't grow beyond. The max is printed when the FS is created, so you can experiment a bit I guess. By doubling the nbpi value, your FS max size gets doubled also.



HTH,

p5wizard

 

[Mag0007]

p5wizard:

Good post! Using JFS.

Checkout:

http://publib.boulder.ibm.com/infoc.../com.ibm.aix.doc/aixbman/prftungd/fsperf1.htm

You bring a good point, now if my DB archive file is larger then 64gig (max for JFS)...I am screwed

 

[p5wizard]

There are still options:

Check whether you can archive your DB to more than 1 file...

Or if you can archive it to a named pipe, while another process reads the pipe, and compresses/gzips/whatever... the stream of data coming out of the pipe and then stores the file. Something along these lines:

# create a new pipe
rm -f /tmp/dbarchpipe
mknod /tmp/dbarchpipe p

# background process to prime the pipe and start reading/compressing/storing
dd if=/tmp/dbarchpipe bs=10240|gzip -c >/backup/dbarchfile.gz &

# create archive of DB and send it to /tmp/dbarchpipe
dbarch_command -outfile=/tmp/dbarchpipe # for you to find out if this is possible...



HTH,

p5wizard