fsadm can not reduce filesystem

[Geoff Wild]

Trying to reduce a file system:

fsadm -F vxfs -b 524288 /data/oracle/irsd
fsadm: /dev/vgoracle1/rlvoljda11 is currently 8704000 sectors - size will be reduced
fsadm: attempt to resize /dev/vgoracle1/rlvoljda11 failed with errno 16

errno 16 means: #define EBUSY 16 /* Mount device busy */

Well, of course it is busy - it is a mounted filesystem with mounted filesystems under it as well.

We are running Online JFS.

I was able to lvreduce it to 512 as lvdisplay shows:

lvdisplay /dev/vgoracle1/lvoljda11
--- Logical volumes ---
LV Name /dev/vgoracle1/lvoljda11
VG Name /dev/vgoracle1
LV Permission read/write
LV Status available/syncd
Mirror copies 0
Consistency Recovery MWC
Schedule parallel
LV Size (Mbytes) 512
Current LE 128
Allocated PE 128
Stripes 0
Stripe Size (Kbytes) 0
Bad block on
Allocation strict

But bdf still shows:

Filesystem kbytes used avail %used Mounted on
/dev/vgjda1/lvojda20
8192000 36431 7645851 0% /data/oracle/irsd/from_irsp

The 8gb disk has already been removed from the volume group and assigned to another. A new file system has been created on a new logical volume (one that resides under the above file system) and was extended with the fsadm command.

Is their a problem with reducing a file system with mounted logical volumes under it?

DO I have to "shudder" reboot?

Thanks...Geoff

[James R. Ferguson]

Hi Geoff:

You may want to try a defragmentation first. Online JFS versions prior to 3.3 do not do a very good job of reducing a filesystem that have extents in the space to be returned.

Regards!

...JRF...

[Sridhar Bhaskarla]

Geoff,

Make sure you have taken backup of the data before you attempt with fsadm.

This is due to the fact that the file system is fragmented. You can defragment it using
fsadm -e -d /mount_point.

and then try reducing.

Otherwise, try reducing in multiples of some size.

For ex.,

fsadm -b 6704000 /mount_point

If this is successful, reduce it further till you are successful.

If this doesnt'work,then you need to schedule a downtime to copy the data (only 36 MB??) to another filesystem. Recreate teh file system and then restore it.

-Sri

[Geoff Wild]

Jaes - sorry forgot to mention that I ran this 3 times first:

fsadm -F vxfs -d -D -e -E /

I think I am in trouble because I ran the lvreduce before the fsadm -b command....

[James R. Ferguson]

Hi Geoff:

If you did an 'lvreduce' *before* the 'fsadm' reduction, I think your filesystem is "toast". If this is the case, I'd look to recreating the logical volume and associated filesystem from scratch, reloading your data from backup.

Regards!

...JRF...

[Sridhar Bhaskarla]

Oops.. Recreate the lvol and restore.

-Sri

[Geoff Wild]

This just doesn't seem right.

If that's the case, then lvreduce should have failed...and why is fsadm reporting errno 16?

I'll keep investigating....but I'm pretty sure I'll have to un mount the filesystems...

[James R. Ferguson · Accepted solution]

Hi Geoff:

Since the filesystem in question is a VxFS one with the Online JFS software, I would not expect the 'lvreduce' to fail, since this would normally be the *second* step in the filesystem's reduction.

If you 'lvreduce'd *before* the 'fsadm' to shrink the filesystem, then you will have corrupted it.

Shrinkage of VxFS filesystems before JFS 3.3 seems to always been problematic with prior defragmentation and/or non-highly utilized filesystems affording more chance of success.

There a lots of references to errno-16 in the Technical Knowledge Base surrounding Online JFS without a seemingly clear pattern to their occurance.

Again, I suggest that you may want to rebuild your filesystem from scratch to the size you want, and reload your data from backup. I believe that you may be forced to do this anyway as noted.

Regards!

...JRF...

[Geoff Wild]

The final answer was to recreate the file system...

Thanks for all the help guys!