Hi Everybody,
I have AIX 4.3 and I have a FileSystem with 400GB size, which called /db/run. Because of grow up of the application's data, more storage has been added 200GB. To add this space without affecting the application & the application's requirements, I have to add this 200GB to the existed FileSystem /db/run. Using SMITTY I tried to increase the Size of the FileSystem /db/run. In fact, the SMITTY take a 100GB only so that the size of the /db/run FileSystem reached 500GB. When I told the problem to some friends, one of them said to me This is because of the limitation of your FileSystem.
When I asked him about the solution of this problem, he suggest as follow:
Backup the all data on that FileSystem.
Delete the FileSystem.
Create the FileSystem again but with PP Size that allow us to add whole 600G to it.
Finally, restoring the data from the backup was taken before.
So if this solution is true? If it is, could any body confirm the steps of this solution, and explain it in more detailed. If the suggested solution above is WRONG, could anybody help me to find out the ideal solution, where the FileSystem size increases to reach 600GB, without LOSING any Data was stored on the FileSystem before.
I have run into similiar types of problems, but usually have been able to into smit chlv and change MAXIMUM NUMBER of LOGICAL PARTITIONS for the logical volume in question. You may have hit the maximum already. I would look into this first before trying the steps your friends have mentioned.
Thanks chosie for your response. Also, I forgot to write some points.
I have a Volume Group called ndbvg which is consists only of this FileSystem /db/run.
The 2nd thing, I remembered the problem really is depending on one of the FileSystem's atrributes that can't be changed after the FileSystem has been created. Because this attribute could be set during the creation process of the FileSystem.
Check the error massage first. What was the error message when you did the smitty and it only increased 100 GB instead of 200GB? If it complained about excess the max space or something like that, then you just need to change the MAX pv for ndbvg, and add 100GB more afterward. If you didn't see any error message, and after smitty, the total FS size became 500GB instead of 600GB, then make sure you've filled in the right number in 512 -byte block.
Your ndbvg shouldn't be striping since you only have /db/run, one lv, I think you should be able to increase it just simply through smitty. But do make sure that the ndbvg is not stripping.
There are some attributes of the vg that can be change without backing up anything, but pp size is not one of them.
Since the threadstarter hasn't provided any data that could shed any light on his problem I'm jsut left to guesses.
Having said this: There are some limitations in jfs which may cause the problem: "Number of Bytes per Inode" and "Allocation Group Size" for instance. In this case the only thing you can do is to back up the FS, drop/recreate it with different values and restore the data.
This is exactly what I was talking about. Time for a little B&R (bakuckup and restore).
If you do have enough space available you can speed things up by making a new FS, mount it on some temporary place, move the data, then umount the old FS, drop it and mount the new FS to the original place.
chvg -t changes only the number of physical partitions in a physical volume and leaves filesystems completely unaffected. What it does is to double the number of possible PPs on a single harddisk. It could be used if you created a VG with, say, 32MB PP-size and now want to use 72GB-disks in it. Beware, though, because the factor also limits the number of physical volumes ("harddisks") the VG can contain. By using factor 2 you are doubling the size but halving the number of disks you can use.