LVM lvreduce and lvextend
Hi
On a Debian squeeze HP Proliant with Smartarray four disk RAID 1+0 135GB
my client's /var volume was in the mid ninety percent full so I proposed that we reduce /home
I executed the following commands :
umount /home
lvreduce -L-20G /dev/LVM/home
lvextend -L+20G /dev/LVM/var
mount /home
the mount didn't go well and I realised that I had omitted a command, so I ran:
resize2fs /dev/LVM/home
Which requested that I run :
e2fsck -f /dev/LVM/home
which produced the following error:
Error reading block 2655233 (Invalid argument). Ignore error<y>?
I ran through the various repair steps that this utility handles and yet the /home volume still won't mount - I get the same result if I run e2fsck again
I don't mind losing the /home volume, but I'd hate (ok worse than hate) to lose the /var
volume
Is there any way to undo these commands or at least to cancel the lvextend on /var ?
I haven't rebooted the server yet.
thanks for your help
yann
On a Debian squeeze HP Proliant with Smartarray four disk RAID 1+0 135GB
my client's /var volume was in the mid ninety percent full so I proposed that we reduce /home
I executed the following commands :
umount /home
lvreduce -L-20G /dev/LVM/home
lvextend -L+20G /dev/LVM/var
mount /home
the mount didn't go well and I realised that I had omitted a command, so I ran:
resize2fs /dev/LVM/home
Which requested that I run :
e2fsck -f /dev/LVM/home
which produced the following error:
Error reading block 2655233 (Invalid argument). Ignore error<y>?
I ran through the various repair steps that this utility handles and yet the /home volume still won't mount - I get the same result if I run e2fsck again
I don't mind losing the /home volume, but I'd hate (ok worse than hate) to lose the /var
volume
Is there any way to undo these commands or at least to cancel the lvextend on /var ?
I haven't rebooted the server yet.
thanks for your help
yann
ASKER
Gosh, way to go to kick a man who's already sprawled across the floor
In fact /var is still running fine. I'm a little afraid of what to expect when I next have to reboot the server
I haven't done anything else than what was specified in my post
My ultimate fear is losing /var which hasn't been backed up yet, for unpardonable reasons.
I guess I could plug a USB drive to run an ad'hoc backup
Any suggestions on this issue ?
Can I simply run:
lvextend -L-20G /dev/LVM/var
to put things back the way they were for /var ?
I don't care about /home since this is a mail server only and the user's mailboxes are on var
I do hope that there are some people with LVM experience lurking around, "des experts quoi" ?
yann
In fact /var is still running fine. I'm a little afraid of what to expect when I next have to reboot the server
I haven't done anything else than what was specified in my post
My ultimate fear is losing /var which hasn't been backed up yet, for unpardonable reasons.
I guess I could plug a USB drive to run an ad'hoc backup
Any suggestions on this issue ?
Can I simply run:
lvextend -L-20G /dev/LVM/var
to put things back the way they were for /var ?
I don't care about /home since this is a mail server only and the user's mailboxes are on var
I do hope that there are some people with LVM experience lurking around, "des experts quoi" ?
yann
1) dont do any LVM resizes
just uncomment filesystem you just broke in fstab and ysstem will boot fine and not touch the sectors where data still resides
now the tricky part....
boot a live USB (ubuntu can mount external LVM)
copy out healthy part of LV to a file (can be NFS)
with fsck (without f or y parameter!!!!) find the locations of expected superblocks
seek for superblocks in LVM's free space....
if they make logical order just add destroyed part to your image file
that is te fastest way....
if LVs are resized after installing system... it is not in order.... call data recovery company...
just uncomment filesystem you just broke in fstab and ysstem will boot fine and not touch the sectors where data still resides
now the tricky part....
boot a live USB (ubuntu can mount external LVM)
copy out healthy part of LV to a file (can be NFS)
with fsck (without f or y parameter!!!!) find the locations of expected superblocks
seek for superblocks in LVM's free space....
if they make logical order just add destroyed part to your image file
that is te fastest way....
if LVs are resized after installing system... it is not in order.... call data recovery company...
ASKER
Ok, a final question and then I'm clear on the issue:
Let's just say that I don't care at all about /home and its contents
All I really want is to end up with a healthy functional /var
Would I be able to dismount /var and run [resize2fs /dev/LVM/]
in order for the added 20Go to be taken into account ?
Or is this categorically the wrong way to go ?
thanks
yann
Let's just say that I don't care at all about /home and its contents
All I really want is to end up with a healthy functional /var
Would I be able to dismount /var and run [resize2fs /dev/LVM/]
in order for the added 20Go to be taken into account ?
Or is this categorically the wrong way to go ?
thanks
yann
You have to resize2fs to minimal size and you can do it while it is running
lvreduce can resize some filesystems while they are mounted
best is to try tp extend by 1G first and check df after if resize2fs kicked in, reduce after.
check uname -r, i resized running lv minute ago on 12.04 LTS with kernel 3.8
i would still suggest at least backing up old size of /home starting from where ext2 of /home starts....
lvreduce can resize some filesystems while they are mounted
best is to try tp extend by 1G first and check df after if resize2fs kicked in, reduce after.
check uname -r, i resized running lv minute ago on 12.04 LTS with kernel 3.8
i would still suggest at least backing up old size of /home starting from where ext2 of /home starts....
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Gheist though helpful didn't respond as accurately as did other respondents in other forums (LinuxForums and LinuxQuestions)
I intentionally dont give dumb clickthrough guide. You have time and manualson your system...
Long:
there is no chance lvextend will allocate same blocks lvreduce freed in same order.
from "man lvreduce"
lvreduce allows you to reduce the size of a logical volume. Be careful when reducing a logical volume’s size, because data in the reduced part is lost!!!
You should therefore ensure that any filesystem on the volume is resized before running lvreduce so that the extents that are to be removed are not in use.
Shrinking snapshot logical volumes (see lvcreate(8) for information to create snapshots) is supported as well. But to change the number of copies in a mirrored logical volume use
lvconvert(8).
Sizes will be rounded if necessary - for example, the volume size must be an exact number of extents and the size of a striped segment must be a multiple of the number of stripes.