Cannot extend logical volume for /var

[Robert Anderson]

I am trying to add more space to my /var mountpoint. It is currently mirrored. According to a vgdisplay, I have 396PE on one disk and 2396 on another available in the volume group. /dev/vg00/lvol8 is currently 244LE and 488PE. I would like to at least double the size. PE are default 4MB. Anyway, I shutdown to single user mode, do a mount -a, umount /dev/vg00/lvol8, then try to extend the lvol. The command I used was:
lvextend -l 976 /dev/vg00/lvol8

The response I got was:
lvextend: not enough free physical extents available. Logical volume "/dev/vg00/lvol8" could not be extended. Failure possibly caused by strict allocation policy.

Any assistance in this matter would be greatly rewarded!

Thanks,
Robert M. Anderson

[Patrick Wallek]

Judging by your post, and making sure my facts are straight, /var is currently has 244 LE's and 488 PE's assigned, so I am going to assume that it is mirrored since PE is exactly twice the LE.

You also say you have 396PE on one disk and 2396 on another. Is the disk with 2396 PE the one that is the mirrored copy?

I think your problem is the when you try to do the extend to 976LE, which is an increase of 732, you are running short of LEs on one of the disks which holds one copy of the mirror of /var. If one disk only has 396 PE, and your mirror policy is strict, then you won't be able to extend the LV because it needs all the extents for the mirror to be on the same disk.

[Stefan Farrelly]

You only have enough free extents on the mirror disk, not the primary disk. With mirroring its disk to disk, so with strict allocation policy on you can only have primary data on one disk and mirrored data on a separate disk.

I would surmise that your primary disk is where /var is and you only have 396 extents available to extend it here. Your mirror disk has a lot more free, 2396, so increasing the mirror wont be a problem.

Still, if currently /var is 244 LE (244*4=976 MB - and mirrored to another 976 MB on the mirror disk) why are you trying to increase it so much, from 244 LE to 976 LE, thats a huge increase from 976 MB to 3.9 GB ! Surely you want to only crease /var a little, say from 976 MB to say 1200 MB. For this use;

lvextend -L 1200 /dev/vg00/lvol8 (Capital L for MB)

For this you do have enough free space on the primary and mirror disks and the command should work fine.

[Edward Alfert_2]

I have always used SAM successfully to extend volumes instead of using command line. It lets you poke around, look at current configuration, see what options are available, and solve problems very easily.

when you are in single user mode just run sam from /usr/sbin/sam

take a look... poking around in a text-gui interface might help you see what you are missing.

[James R. Ferguson]

Hi Robert:

You undoubtedly have "strict" allocation for /var. Look at the allocation policy with:

# lvdisplay /dev/vg00/lvolX

You will probably see "Allocation strict". Mirror copies of a logical extent can be allocated to share or not share the same physical volume or physical volume group. For strict allocation, mirrors of a logical extent cannot share the same physical volume. This is the default.

...JRF...

[Magdi KAMAL]

Hi Robert,

I got your point !

Your command is "lvextend -l 976 /dev/vg00/lvol8"

This extends in number of LOGICAL EXTENT so you may use it like : "lvextend -l 244 /dev/vg00/lvol8 "

If you want to express the extention in MegaBytes , it's :

lvextend -L 976 /dev/vg00/lvol8

Note:

-l lowercase L expresses LE.
-L Uppercase L expresses MB.

Magdi

[Robert Anderson]

Thanks for all of your ideas guys! To clarify, Maybe 3.9MB is too large, I just don't wanna be going in every 2 weeks to try to extend it again. We have installed a production instance of Oracle as well as an EDI product from Harbinger on this machine. In a matter of 3 days, it has jumped from 60% to full. As you may know, when /var is full, things tend to stop running and lock up. I want to make sure there is enough room to allow us time to notice when something is logging erratically and correct the problem before it locks up our database.

Robert M. Anderson

[linuxfan]

Hi Robert,

Looks you have some logical volumes defined, which are not mirrored on the primary disk.

One of the ways you can fix this is figure out which LVs are defined only one disk and then pvmove them to the other disk, what this would do is free up some PEs on the first disk and then you can increase /var.

you can do something simple like
vgdisplay -v /dev/vg00 |egrep "LV Name | Used PV"
which would return the LV Name and the number of physical volumes used, this would help you figure out which LV hasn't been mirrored.
You can then use pvmove , for example lvol9 is not mirrored and your disks are c0t0d0 and c1t1d1, you could do something like
pvmove /dev/vg00/lvol9 /dev/dsk/c0t0d0 /dev/dsk/c1t1d1

(Make sure you have a good backup just as a precautionary measure)

-HTH
Ramesh

[Patrick Wallek]

What area in /var caused it to fill up? /var/tmp? /var/adm/syslog? If there is one directory that is perpetually causing /var to fill up, how about making that directory its own mount point? You can create a new LV of some size, and mount it as /var/tmp for example. Then if /var/tmp fills up, the rest of /var is OK.

[James R. Ferguson]

Hi Robert:

Given your last comment, I'd also consider creating some symbolic links from various subdirectories of /var to some new mountpoints. This should not only improve performance but allow you to monitor and manage the containers that fill the most rapidly.

Regards!

...JRF...

[Richard Darling]

Robert, I had a similar problem, and we did what Patrick suggested; set up a separate mount point. It solved my problem.