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

Hello,

I should warn you: I use the term "partition" to refer to the logical volume simply because that is how fsck looks at things. For all intents and purposes, close enough.

The big thing to realize is that fsck is only going to operate within the stated boundaries of the /dev/LVM/home partition. When you ran lvresize on /dev/LVM/home, you reduced the boundaries of the partition to somewhere within the filesystem. I would resize both partitions back to where they were, run fsck then restart resizing things.

By the way, resize2fs will ALWAYS require you to use the force option.

I recommend the following procedures:

If reducing a filesystem:

1. unmount the partition
2. shrink the filesystem more than you want to reduce the partition size. In your case, use resize2fs to reduce /dev/LVM/home by 21 or so gigabytes. Using the -M option will shrink the filesystem to the minimum size.
3. reduce the partition size. In your case:
   
   Code:

   lvreduce -L-20G /dev/LVM/home

4. resize the filesystem in /dev/LVM/home back up to the partition boundaries.
   
   Code:

   resize2fs -f /dev/LVM/home

5. remount /home

if increasing the partition

1. unmount the partition
2. increase the partition size (there is a -l option to use all of a Volume Group's free space too)
   
   Code:

   lvextend -L+20G /dev/LVM/var

3. resize the filesystem
   
   Code:

   resize2fs -F /dev/LVM/var

4. remount /var

Thanks for your detailed response Jason_not

I feel a sense of hope that the worse is not nigh

The only uncertitude lingering in my mind is how to
apply your recommendations in my present state

I haven't done anything more or less than what was
detailed in my post, and all in that order

This is purely a mail server (postfix/dovecot/roundcube)
and at present /var is still running fine and users
haven't endured any disruptions - I don't care about
/home it isn't in use

I'd like to follow your instructions but I'm not sure
how to move: forwards, or backwards as may be required

yann

You haven't done anything to the /var filesystem yet - apparently. If you haven't done a resize2fs on it, it is still the original size within the now larger lv. Safe to reduce that. But you have to be real careful reducing as you already found out - personally I never trust the space options on the command; you never know what rounding is being done. And in your case that is also true of the RAID controller. I always leave a bit extra to be on the safe side, but that might still overlap in your case.

So you should be ok to lvreduce the /var lv, lxextend the /home back to their original sizes and all will be well after the fscks. Seems to work most of the time from what users report here on LQ and elsewhere. Would have been better had the fsck not been run I suspect - it fixes filesystems, not necessarily taking care of the files within.

Note my sigline.

Thanks Syg, now at least I have a way forwards (or backwards as is the case)
yann

Hello,

I agree with Syg00: play it safe: try this:

1) reduce the /var filesyste by... 25 gigabytes if you can, using resize2fs
2) reduce the /var partition by about ... 40 gigabytes (you increased by 20, now go 20 more) with lvresize
3) resize2fs /var to the max it can go.
4) increase the /home parition by 21 gigabytes (1 gigabyte more than you reduced it before...) with lvresize
5) run fsck -f on /home

if that comes out clean,

6) reduce /home filesystem by 21 gigabytes (or whatever to get to your original target size) with resize2fs
7) reduce the /home parition by 20 gigabyte (leave some overlap so you don't cut off the end of your filesystem) with lvresize
8) resize2fs to the max on /home

9) increase /var's partition size to your target with lvresize
10) resize2fs /var
11) reboot.

Gosh Jason, seems a little excessive
I don't even have that much leeway to begin with
- anyway there was probably only 1MB of unused space
on the RAID volume. I don't see how specifying larger
LVs can work.

Someone recommended against shrinking, which at the
moment I'm inclined to agree with, lest I mess things
up any further

Well, I understand and partially agree. I chose arbitrary numbers based on how much space you moved around in the first place. If you use megabytes as your units, things will still work out.

Definitely adjust the numbers as necessary: it all relies on the following axioms I go by:

1) never reduce the partition below the filesystem size (partition size must be >= filesystem size)
2) always include wiggle-room between the filesystem limits and the partition (lv) size. it all depends on where someone rounded numbers off, and since lvresize and resize2fs are two different programs, I like to be safe.
3) As far as the filesystem is concerned (not in use, etc) resize2fs has options to let you reduce its size down to the current amount of space used. the -M option (I believe) is a decent thing as it allows you to reduce the size the most but still be safe.


So altering the size of /var was mostly to get a perfectly functional filesystem out of the way and give /home as much room to get fixed as possible. Just so long as you follow 1 and 2, things should be fine. After /home is fixed (or deleted...) you can then work on moving disk space around.

But then, what I deem reasonable, isn't necessarily in someone else's eyes...

I understand, and agree about your reluctance regarding shrinkage. I have tried using resize2fs to go smaller than the amount of data used in a filesystem and it wouldn't let me.

BTW: If you aren't already, I heartily suggest you do all of this in either single user mode, or via a rescue boot.

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 scenario

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

Ok, that really simplifies things:

1. lvremove /dev/LVM/home
2. lvextend /dev/LVM/var (I think you already did this)
3. resize2fs /dev/LVM/var (this will expand the filesystem to the partition size)
4. mount /dev/LVM/var /var

All of the complications came about because /dev/LVM/home's partition was shrunk below the filesystem size. The part with /dev/LVM/var was just fine however. So once you have /var settled, create a new logical volume. My example below assumes you call it "home", the Volume Group is called "LVM", and that you wish to use 100% of the remaining unused space in the Volume Group.

--jason

You don't even need to to that much. You do need to run the "resize2fs /dev/LVM/var" to expand that filesystem to fill its enlarged container. Since you already have a volume for /home, you just need to run the appropriate "mkfs.ext{2,3,4} /dev/LVM/home" for the type of filesystem you want there, replacing the patched-up filesystem that fsck repaired.

yes, that's also true.

So, the answer to your last question Yann, is YES and no there is nothing wrong with that approach.

--jason