not comfortable to do lvreduce

[apple]

Dear HPUX Gurus,
I've extended vg02 in hpux 11.23, extend the lv and finally fsadm, but i encountered this error as attached. and the filesystem is not increased at all. when i issue vgdisplay vg02, the free PE is zero. what should i do now? i'm afraid to do lvreduce. would really appreciate your advice. many thanks in advance

[Patrick Wallek]

You don't need to lvredue.

The error shows that the filesystem is full, which is probably why you want to increase it. However, fsadm cannot run correctly if the filesystem is full. You need to temporarily move some files out of the filesystem and see if you can get it down to 99% usage. Then run your fsadm command.

[Matti_Kurkela · Accepted solution]

The LV was successfully extended, but extending the filesystem inside the LV failed because the filesystem became 100% full.

The fsadm command needs some free space to successfully extend the filesystem.

You have several options:

1.) Move some files temporarily away from this LV so that you get some free space in the filesystem (as displayed by the bdf command). Then re-execute the fsadm command.

After the fsadm command is successful, you can move the temporarily-moved files back to their original location.

2.) If you cannot move any files even temporarily, you must stop the applications that use this filesystem, unmount the filesystem and then use extendfs to extend the filesystem in off-line mode.
Extendfs will automatically detect the size of the LV and will extend the filesystem to match the filesystem size. See "man extendfs".

3.) If you wish to undo your LV extension operation, you can use lvreduce to shrink the LV back to its original size, thus freeing some PEs. At this point, none of the capacity you added by extending the LV is actually used, so lvreduce is safe - but you *must not* reduce the LV so far it becomes smaller than the filesystem in it.

Use the "fstyp -v /dev/vg02/" command to find the current size of the filesystem, if you're unsure: multiply the f_blocks value with f_frsize, and you'll get the filesystem's current size in bytes. Divide with 1024 to get kilobytes, and again with 1024 to get megabytes. This is the target value for your lvreduce.

Rules of thumb:
Filesystem size = LV size: all is well.
Filesystem size < LV size: wasteful, but data is not corrupted.
Filesystem size > LV size: data may be corrupted. Never allow this to happen!

MK

[apple]

very great reply. would like to seek further clarification, the previous and current utilisation when i issue bdf is 93% utilised. actually i have accidentally issued this command newfs -F vxfs instead of fsadm. after wrongly issued, i issue fsadm
looking at options, if i would like to lvreduce (the previous PE is 53 and i extended another 53), meaning when i issue this one, there is no impact

lvreduce -l 53 /dev/vg03/lvol01
and then reextend back
lvextend -l 106 /dev/vg03/lvol03
fsadm -F vxfs -b 27136M /u01
is it safe like this? hope to hear from you. thank you

[Eric SAUBIGNAC]

Bonjour,

I see no need to reduce LV then extend it again. As explained before, the problem is inside the FS itself.

Forget lvreduce/lvextend and try to unfragment the FS before extending it with : "fsadm -d -D -e -E /u1"

You can add "-v" option to have it more verbose ... and it will be ! Be aware that it can be a long process.

After try again "fsadm -b 27136M ..."

Assuming your PE Size is 256 Mo (control with vgchange), your new fsadm command with size 27136M (106 extents x 256 Mo) is better than the first one with 22016M

Hope this will help

Regards

[Siju Vadakkan]

lvreduce -l 53 /dev/vg03/lvol01
and then reextend back
lvextend -l 106 /dev/vg03/lvol03
fsadm -F vxfs -b 27136M /u01
is it safe like this? hope to hear from you. thank you
-----------------------
the steps are OK , if ur PE size is 256M(27136/106=256).
I don't understand the logic , why u want to reduce and and again extend( what i under stood is, LV is already with 106 PE's)
.U just need to exend the filesystem with fsadm.

Do lvdisplay and see the current size , it should be 27136m, if so u can extend it directly without reducing the LV.

would appreciate if u can provide

1. vgdisplay vgname
2. lvdisplay lvname and bdf

[BW Moll]

Reducing a logical volume is not something that I personally enjoy doing. Personally I would tar the entire filesystem to tape using tar -cvf or to a disk file first.

Once you have the data safeguarded as a tar file, you can always delete the lv, then create it at the size you wish to make it. Then take your tarfile and restore the data to the mount point using tar -xvf

Using tar keeps the permissions as they were before...

[apple]

i was thinking of reduce the lv and delete from our HP SAN storage the LUN. defragment is very great, but i'm afraid it's gonna take very long time. i have get the downtime from the users, and will try to umount and extendfs the file system. what do you think? will give good points after lunch. thanks a lot.

[john123]

for defragmentation there is no down time required. You can do it while the LV is active but the only thing you may need to consider is that defragmentation is a i/o intensive work and the server may suffer a i/o bottleneck at this time.

[Mridul Shrivastava]

You mentioned that accidentaly you have executed newfs when filesystem was mounted so I think that must have failed since lvol was aleady mounted.

Now as far as lvreduce and extend the lv again concerned that is quite ok and there won't be any harm since you never extended the filesystem. Make sure that you reduce by only those no. of PEs by which you have extended it earlier. Else you might end up losing data.

If you are doing it offile then I would suggest to take backup of the filesystem. Anyways it is always a good idea to have a system backup as well ;)

[Matti_Kurkela]

Almond08, your lvreduce/lvextend procedure looks safe but I do not see how it would help.

The problem that stopped fsadm was inside the filesystem (in its current state) - so why would it be fixed by making changes to the empty space you're going to add to that filesystem? The new space is not a part of the filesystem yet - and won't be until fsadm or extendfs completes succesfully.

(The vx_nospace message was coming from the kernel, not from fsadm: maybe some program tried to create a large temporary file and failed because there was not enough space for it. This request of space may have caused the fsadm to stop. If bdf now says the disk is only 93% full, I would try fsadm again.)

I would be much more worried about the accidental newfs command.

Nothing in the newfs/mkfs manual pages indicates that newfs would check if the filesystem is mounted or not. Unless the newfs command specifically said it's stopping because there is an active, mounted filesystem on the LV already, I'm afraid that newfs command may have corrupted your filesystem.

To be absolutely sure, I would recommend unmounting & re-mounting that filesystem - but if you do that, make sure you have up-to-date backups first. *If* the newfs damaged your filesystem, the filesystem may currently be working only because the memory caches held a valid copy of the filesystem metadata.

Unmounting will cause the kernel to sync all relevant caches to the disk, and then to completely "close the books" on this filesystem. Mounting the filesystem back will re-initialize the in-memory information about this filesystem with true values read from the disk. If newfs did some damage, it should become detectable at this point. Either the mount command will say you'll need to run fsck, or you will see your filesystem is now totally clean and empty. If that's the case, the next step will be a restore operation.

If the filesystem can be cleanly re-mounted and all the data is intact, you can be confident your accidental newfs did not cause any damage.

MK

[apple]

thanks a lot for your great reply. keep it up. :)