Shrinking of Veritas filesystem fails, blocks allegedly still in use

[Ralph Grothe]

Hi,

I did the common typo when creating an LV by not holding the shift key pressed when needing to specify "-L" (i.e. the fat finger syndrome as some of you like to call it).
Thus I wasted far too many PEs on a fairly static filesystem,
viz.

[root@hades:/root]
# bdf /opt/perl5
Filesystem kbytes used avail %used Mounted on
/dev/vg00/lvol11 409600 56704 347416 14% /opt/perl5


What I wanted instead of 100 LEs was 100 MBs.

Now I'm trying in vain to reorganize the blocks in order to be able to reduce the filesystem.

I tried this (with varying numbers of passes):

# fsadm -F vxfs -d -e -p 20 /opt/perl5

# fsadm -F vxfs -D -E /opt/perl5

Directory Fragmentation Report
Dirs Total Immed Immeds Dirs to Blocks to
Searched Blocks Dirs to Add Reduce Reduce
total 295 70 229 0 0 0

Extent Fragmentation Report
Total Average Average Total
Files File Blks # Extents Free Blks
2429 5 1 88224
blocks used for indirects: 0
% Free blocks in extents smaller than 64 blks: 0.11
% Free blocks in extents smaller than 8 blks: 0.02
% blks allocated to extents 64 blks or larger: 47.26
Free Extents By Size
1: 2 2: 3 4: 2
8: 2 16: 2 32: 1
64: 1 128: 2 256: 1
512: 1 1024: 1 2048: 2
4096: 0 8192: 0 16384: 1
32768: 2 65536: 0 131072: 0
262144: 0 524288: 0 1048576: 0
2097152: 0 4194304: 0 8388608: 0
16777216: 0 33554432: 0 67108864: 0
134217728: 0 268435456: 0 536870912: 0
1073741824: 0 2147483648: 0



After those runs I tried to shrink the FS in successively increasing sizes like this, but always got rejected:

[root@hades:/root]
# fsadm -b $((100*1024)) /opt/perl5
fsadm: /etc/default/fs is used for determining the file system type
vxfs fsadm: /dev/vg00/rlvol11 is currently 409600 sectors - size will be reduced

vxfs fsadm: allocations found in shrink range, moving data
vxfs fsadm: cannot shrink /dev/vg00/rlvol11 - blocks are currently in use.
[root@hades:/root]
# fsadm -b 200M /opt/perl5
fsadm: /etc/default/fs is used for determining the file system type
vxfs fsadm: /dev/vg00/rlvol11 is currently 409600 sectors - size will be reduced

vxfs fsadm: allocations found in shrink range, moving data
vxfs fsadm: cannot shrink /dev/vg00/rlvol11 - blocks are currently in use.


I know, by now it would have been quicker to create a new LV and copy the stuff in sito.

But I would like to know for later cases where the filesystems might be more important and where I lack such opportunities how to overcome this hiddeous "blocks in use" rejection.

Btw. I remounted /opt/perl5 in between a couple of times in the vague hope of enforcing somehow a "cease-usage" of extends,
which of course was silly.

Any reorganization hacks from you Veritas-gurus?

[Ralph Grothe]

[root@hades:/root]
Forgot to supply some filesystem details.
Hope this will suffice:

# fstyp -v /dev/vg00/rlvol11
vxfs
version: 4
f_bsize: 8192
f_frsize: 4096
f_blocks: 102400
f_bfree: 88224
f_bavail: 86846
f_files: 24896
f_ffree: 22048
f_favail: 22048
f_fsid: 1073741835
f_basetype: vxfs
f_namemax: 254
f_magic: a501fcf5
f_featurebits: 0
f_flag: 0
f_fsindex: 5
f_size: 102400

[Massimo Bianchi]

Hi,
just a try:
specify directly that it is a vxfs FS with the option -F vxfs, but overall: is the directory lost+found there ?

ll /opt/perl5/lost+found

Massimo

[Pete Randall]

Ralph,

Well, I was going to recommend the new lvol thing, but you obviously already thought of that.

All I can say is that I've rarely been successful in shrinking a file system with OnlineJFS. I've always run into the scenario you describe, and re-orgs rarely help enough. I generally don't even bother trying anymore and just go with the new lvol route.

I'm seriously considering dropping the use of OnlineJFS.


Pete

[Paulo A G Fessel]

Are you using PERL standalone or as part of some Web application (mod_perl of Apache comes to mind)?

If it's the case, perhaps you can't move blocks because they may be in use by mod_perl (or some other application that's using PERL).

Just my .02,

Paulo Fessel

[Steven E. Protter]

Have you tried booting the system, defragmenting it(presumably with fsadm, haven't bought my Online JFS yet) and trying again?

Perhaps this can be done at run level 1 so no networking is present and no users can be on the system.

If it sounds like a stupid suggestion, thats okay, just checking.

SEP

[Tim Adamson_1]

Unfortunately, I think the only way for you to get around the problem is to either create another lvol and copy the data across or blow it away and restore from backups.

The other way would be to incorporate it into an Ignite recovery test and interact with the recovery and reduce the filesystem size.


Tim

[Tom Danzig]

I haven't had much luck reducing file systems on vxfs vesion 3 file systems. You may want to try to try and upgrade to version 4 (vxupgrade -n 4 /mount_point) which I've found works much better.

Be aware that I have read on these forums (from the HP master himself - Bill Hassel) that using vxadm to reduce file systems should be considered as experimental only and to make sure you have a good backup.

[Con O'Kelly]

Hi

I'm surprised you're having issues reducing the FS using Online JFS. There were certainly issues with filesystems using a version 3 layout but as you're using version 4 you should have been OK. I have to say from my experience I have never had an issue reducing filesystems with version 4 disk layout.

Looking at the JFS/OnLine JFS chapter in the HP-UX Software Recovery Handbook (copy attached), it says that only filesystems that are multiples of 32MB can be reduced online. However I'm not sure if this refers to version 4 layout as well. Looking at your info, it appears your lvol is 400MB which is not a multiple of 32.
I do remember hearing in the past that you had to be careful of the sizing of logical volumes if you wanted to reduce them in the future (something to do with the way extents are allocated) but I assumed this was all fixed in the latest releases.

The only thing I could recommend is checking your Online JFS version & patches.

Cheers
Con

[Con O'Kelly]

Sorry didn't attach it....!!