fsadm on EMC

[Alan Riggs]

I am attempting to use fsadm to reduce a filesystem residing on an EMC 8340. I recewive the following error message:

fsadm: attempt to resize /dev/vgsan13/rlv_vertex failed with errno 16

The filesystem is not full and no extents should extend beyond the new size limit. Fsadm works fine to reduce filesystems on local JBOD.

[Eileen Millen]

Have you tried to do it with SAM?
I have never had to reduce on our EMC.

Eileen

[Roger Baptiste]

>>fsadm: attempt to
>>resize /dev/vgsan13/rlv_vertex failed with errno 16


Errno 16: -> Mount device busy as per the error codes.
Make sure the lv is not being
used by any process , before
running the fsadm. Since you
are reducing the FS, it may
be trying to remove a block
which is currently held by
a process.

To check:
fuser -cu

On a related note, are you
sure you want to reduce the
volume? There is a chance
that you can lose data.

-Raj

[Alan Riggs]

I never use SAM for LVM work. A quick check shows no way to reduce the size of a filesystem.

No processes are attached to the mountpoint. Fuser shows it clear and I can even umount it.

Yes, I want to reduce the size. I am certain that no data resides on the back half of the filesystem.

I have workarounds that will let me accomplish the same thing in this case, but I want to know whether there is an issue with fsadm on EMC devices (one can never tell what teh future will bring).

[harry d brown jr]

fuser is weak, do you have lsof? if not try downloading it from:

http://hpux.connect.org.uk/hppd/hpux/Sysadmin/lsof-4.55/

Why not just newfs it?


live free or die
harry

[Alan Riggs]

I have lsof. The fact that I can umount the filesystem is sufficient demonstration that there are no processes attached.

I do not wish to newfs (or mkfs) the filesystem because it contains data that I would prefer to keep. My users are funny that way.

[Wodisch]

Hello Alan,

I am afraid, you have the wrong filesystem...
You have JFS3.0, but you will need JFS3.3, for actually reducing filesystems :-(
With JFS3.0 quite often some i-nodes (and the like) where allocated in just that part of the LV which you wanted to free... And even the options "-E/-e" and "-D/-d" did NOT move it.
JFS3.3 is much better there :-)

Sorry,
Wodisch

[James R. Ferguson]

Hi Alan:

I've never heard of much success shrinking a filesystem with Online JFS. The Knowledge Base is replete with documents noting all patches current / reason unknown for failure to shrink a filesystem.

I presume you have followed the usual defragmentation suggestion(s) before attempting the shrinkage.

You indicate that you have ample free extents, but I wonder if at *one time* the filesystem did extend into the extents you are now trying to free.

Regards!

...JRF...

[Tony Constantine_1]

Hello Alan

I've come across this before on a normal 2gb internal drive. The lv was 80% full and when fsadm trying to reduce the volume was getting errno 16. In /usr/inculde/sys/errno.h refers errno 16 as being down to Mount device busy. Anyway try doing a defrag on the lv

fsadm -d -v -e /filesystem

If this does not work can you remove any unwanted data or temporarily move some data then try the defrag again, hopefully the fsadm will reduce the lv

Regards

Tony

[Alan Riggs]

My JFS is not the problem. As I posted above, I am able to successfully reduce a filesystem sitting on JBOD on the same machine.

It is not a problem with "stray extents". An attempt to reduce a filesystem that has extents in use beyond the specified range results in the error "cannot shrink . . . inodes are currently in use." I am getting, "attempt to resize . . . failed with errno 16".