Hi,
is anyone aware about filesystem size restrictions on AIX? And does anyone know a solution for below problem?
I have 2 boxes attached to EMC Raid5 storage, both have huge /optware/oracle/oradata filesystems - 4.5 and 2.5 TB in size, nothing is striped or in any other way restricted. Due to system optimization, I migrated off a couple of databases - now I have about 2 TB free space in the 4.5 TB filesystem and more than 1 TB in the other one - which I would like to reclaim for reusage somewhere else - but I cannot reduce the filesystem sizes by any amount of space. When I issue the command, it never finishes - its not erroring out, its just running without doing anything. Extending the filesystems still works - though it coredumps but the size at least changes. But reducing doesnt work at all.
Does anybody know another solution for me than migrating off the remains and just dropping the filesystems?
I raised this already with EMC and IBM but both did not come back with any solution other than drop and recreate - and I'd like to avoid re-occurrence on other systems hence the restriction question.
Didn't had that problem yet - though if IBM and EMC recommend dropping and create anew to be on the safe side, I would do that too even it might be a lot of work.
Is the VG where these FS'es reside of type Scalable?
yes the VGs are scalable - 185 luns 33 GB each in both VGs - filesystems are spread across max - so parts of them are on all 185 luns ... 2 different servers, similar setup - AIX 5.3 TL7 SP5 (but we had the problem already running TL5) - other filesystems (smaller ones) in the same VG don't face this issue. Interesting maybe that commands like fileplace do fail on the huge filesystems too, but work properly in the smaller ones...
Another thought: You said, that you use an inter policy of maximum spreading the LV over 185 LUNs thus. Try to change the policy back to minumum and then try to reduce size again. This is worth a try as the inter policy seems to influence allocp considerably.
(Depending on your SAN you might not need to use an inter policy of maximum if you spread your LUNs evenly over many disks already.E.g. if you spread a number of LUNs over the same rank/shelve/whatever the LV on those LUNs utilise all physical disks already. Hence no need to add another layer of complexity for data distribution. It might even be that I/O speeds up if you spare LVM from doing this extra work.)
I've had simular issues when attempting to shrink a filesystem. I am far from a guru but I found sometimes I don't have enough room to shrink of that makes any since. So instead of shrinking by large numbers I went to small and stepped my way up. I reduced by 1G then 2 then More gig... It compounded pretty quick.
I would test my simplistic theory by tring to shrink by One Gig and see what you get.
Remember that "defragfs" does NOT mean "defrag filesystem". Rather it means "defrag free space". This info came to me from the mouth of one of the AIX developers at the AIX Technical University this past year.
I've run into this same problem numerous times. I'll have 3 gig free in a filesystem and try to shrink it down by 1 gig to assign some place else. It then spits out those errors saying it can't shrink it.
The problem is that the data is too spread out physically on the disk. The only way you can reduce the size of an JFS2 filesystem that won't shrink, that I know of, is to create another filesystem big enough to hold all the data, copy it over, shrink the original JFS2 filesystem (or even recreate it if you have to), and then copy the data back over to it.
I have meanwhile removed my filesystems - and identified the rootcause - apparently the magical limit seems to be the 2 TB filesystem size - once you pass this size you can still extend but no more reduce the filesystem size - no matter how many free pps or even disks you have. reorg and defrag don't help and even freeing up whole disks doesnt make anything any better.
IBM is aware about this problem but doesnt have a solution - their comment - nothing we can do ...
Rgds
zxmaus
