Defrag is not helping to free up unused space

[skt_skt]

HP-UX 11.11

#vxlicense -p

vrts:vxlicense: INFO: Feature name: HP_OnlineJFS [50]
vrts:vxlicense: INFO: Number of licenses: 1 (non-floating)
vrts:vxlicense: INFO: Expiration date: No expiration date
vrts:vxlicense: INFO: Release Level: 22
vrts:vxlicense: INFO: Machine Class: All
vrts:vxlicense: INFO: Site ID: 0

#bdf /opt
Filesystem kbytes used avail %used Mounted on
/dev/vg00/lvol5 7700480 1919354 5427817 26% /opt


Tried following and completed succesfully. But still fsadm is failing.

6 fsadm -F vxfs -e -E /opt
7 fsadm -F vxfs -b 6512M /opt

8 fsadm -F vxfs -d -D -e -E /opt
9 fsadm -F vxfs -b 6512M /opt

fsadm -F vxfs -b 6512M /opt
vxfs fsadm: /dev/vg00/rlvol5 is currently 7700480 sectors - size will be reduced
vxfs fsadm: allocations found in shrink range, moving data
vxfs fsadm: cannot shrink /dev/vg00/rlvol5 - blocks are currently in use.

lvdisplay /dev/vg00/lvol5
--- Logical volumes ---
LV Name /dev/vg00/lvol5
VG Name /dev/vg00
LV Permission read/write
LV Status available/syncd
Mirror copies 1
Consistency Recovery MWC
Schedule parallel
LV Size (Mbytes) 7520
Current LE 235
Allocated PE 470
Stripes 0
Stripe Size (Kbytes) 0
Bad block on
Allocation strict
IO Timeout (Seconds) default


Any way to get the free space removed from LV?

[Steven E. Protter]

Shalom,

defragmentation does not free up space.

It insures that files are written contiguously, and not spread out in multiple locations.

This improves read performance down the line.

I believe the cause of the error above is you are trying to reduce the logical volume to much, Try a less drastic reduction and this will work.

SEP

[James R. Ferguson]

Hi:

Interestingly, on 11.23, PHCO_38434 addresses the error "blocks are currently in use". There doesn't seem to be an equivalent patch for 11.11.

What JFS version are you running?

Regards!

...JRF...

[skt_skt]

JFS version is 3.3 (B.03.20.1)

[skt_skt]

i could reduce 122M by going via small reduction. But not further

[James R. Ferguson]

Hi:

You might try quiesing the filesystem. Bootup into single user mode if necessary, mount the filesystem and try again.

Later versions of VxFS offer better chances of success, although a couple of defragmentation attempts might suffice.

Regards!

...JRF...

[James R. Ferguson]

Hi (again):

Did you try my suggestion to quiesce the fileystem and/or run multiple defragmentations?

...JRF...

[skt_skt]

i did not understand your "quiesing and/or multiple defragmentations".can you explain better?

Also i cant dismount the file system.

[James R. Ferguson]

Hi (gain):

> i did not understand your "quiesing and/or multiple defragmentations".can you explain better?

I'm sorry. This means to make quiet. That is, if you could stop any processes using the filesystem you might be able to perform the size change.

> Also i cant dismount the file system.

In that case, I would try several defragmentation runs in succession.

Regards!

...JRF...

[Patrick Wallek]

quiesce means "to quiet", ie. to have very little activity happening on the filesystem.

Multiple defrags -- Run your command multiple times to see if you can get incrementally better results.

>>cant dismount the file system.

That kind of throws the quiesce request out the windows then.

[James R. Ferguson]

Hi (again):

What is you filesystem layout version? If it isn't <4> try upgrading to that version; defragment again; and try your size reduction again:

# mkfs -F vxfs -m /dev/vg00/lvol5

See the manpages for 'vxupgrade(1M)'

Regards!

...JRF...

[skt_skt]

i am at version 4

#mkfs -m /dev/vg00/lvol7
mkfs -F vxfs -o ninode=unlimited,bsize=1024,version=4,inosize=256,logsize=1024,nolargefiles /dev/vg00/lvol7 7720960

[James R. Ferguson]

HI (again):

Have you tried running multiple defragmentations and if so, does this gain you any ability to reduce the filesystem?

There may come a point, if you are determined to shrink this filesystem, that you should consider trying in single-user mode. If that doesn't work, and you *still* insist on resizing, either (1) backup the filesystem; 'lvreduce' the logical volume size; 'newfs' the filesystem and reload it; or (2) use Ignite to rebuilt and reconfigure the sizes of your mountpoints.

I fully understand that you have said that you "can't" quiet or otherwise unmount the filesystem. You may have to choose among your options, however.

...JRF...

[TwoProc]

I'm guessing you've got "free space" out there that you can't use because although the file is deleted, the space hasn't been given back to you yet. Is this what your problem is?

If so, some process is holding the *inode* of the file. The space won't free up until the process dies/quits. You can use "lsof" to determine what process is holding the inode open. If you don't have "lsof" you can get it from any of the "HPUX Porting Archive", the URL address of which can be obtained by using Google and searching for "HPUX Porting Archive".