Raffaele Morelli wrote:
> Eduardo M KALINOWSKI wrote:
> > You seem to be using lvm. Can't you shrink another partition to grow root?
>
> Yes I could... but I have never managed lvm and this is a production
> server..
You are using LVM. You have plenty of space. You just need to move
it around a little bit.
> /dev/mapper/debian-root 322M 213M 93M 70% /
> /dev/mapper/debian-usr 4,6G 1,2G 3,2G 28% /usr
> /dev/mapper/debian-var 2,8G 1,6G 1,1G 61% /var
> /dev/mapper/debian-home 519G 16G 477G 4% /home
Unfortunately the debian-installer's default lvm allocation is a
little bit small for root. And by default the last partition gets
*everything* else remaining on the disk. That causes /home to be huge
and everything else to be small. Small is okay. Small is better than
too large. Because it is easy to expand. Shrinking is more difficult.
But you are using LVM and so can fix it up! No problem! You have
plenty of space. Just not in the right place.
Please confirm that you are using ext3 for your filesystems. That
would have been the default. But you might have chosen something else
at installation time.
df -T
Confirm that you don't have any free space left.
# vgs
VG #PV #LV #SN Attr VSize VFree
v6 4 14 0 wz--n- 931.03g 44.34g
The VFree column shows unallocated LVM free space that can be applied
immediately. I expect in your case it will either be zero or very
small. The task is to make some free space so that it can be
allocated to root.
Since /home is the large bucket of space and only 16G used 4% then it
is the one to take from. All of this can be done on the fly. But
you said this is a production server.
If you could play with a non-production victim machine to gain
experience before working on the production machine it would be a lot
safer. Or a VM. Using a VM for this would be fine too. Get
comfortable with the tasks elsewhere and then apply them to the
production machine. This can be done with the server up and (mostly)
online.
First see that /home is not busy. Because we must unmount it to
shrink it smaller.
# lsof /home
Any output shows processes that are running and holding that mount
point busy. As long as processes are running there the /home cannot
be unmounted. But we need to be able to unmount it.
# umount /home
That will fail if processes are running in /home. So figure out what
is happening there and work around them. Stop them. Log people out.
Whatever. That is not known to us. Only you can know how to make
that mount point not busy so that it can be unmounted.
Assuming that you can umount /home then shrink it. Noting that
/dev/mapper/debian-home is your device from the above then something
like this to reduce it to 100G since you are only using 14G at the
moment. DO NOT REDUCE IT SMALLER THAN YOUR DATA SIZE!
# umount /home
# e2fsck -f /dev/mapper/debian-home
# resize2fs -p -M /dev/mapper//debian-home
The filesystem on /dev/mapper/debian-home is now ZZZZ blocks long.
# lvreduce -L50G /dev/mapper/debian-home
# resize2fs -p /dev/mapper/debian-home
# mount /home
Here are some comments about the above. Unmount it. It must be fsck
checked before resize2fs will work with it. resize2fs -p to show
progress as it runs. resize2fs -M to reduce the filesystem to minimum
size. That will be near but somewhat larger than the 14G shown in the
df output. There is some overhead that I haven't tracked. lvreduce
to the fixed size that you want which must be larger than the minimum
filesystem size! If you make it smaller then you will lose data. But
make it enough larger to fit the data. Then resize the filesystem
back up to fit the current size.
Having done that successfully then you will have free space that can
be allocated elsewhere. That was the goal of the above.
# vgs
VG #PV #LV #SN Attr VSize VFree
v1 3 11 0 wz--n- 931.03g 394.05g
^^^^^^^
Free space can then be allocated to the root or other filesystem.
That part is very easy. It can be done on the fly without
unmounting. Running tasks will never know. There will just be more
filesystem space available.
Since you only have 322M on root I would be inclined to set the new
size to a fixed larger size instead of a relative incremental. Let's
say you want the new size to be 3G. Set the new larger size this
way. Then resize to the larger size. This is done on the fly. You
have plenty of disk so I would be inclined to choose 3G for the root
partition size. There is no right size. It is a judgement call.
If you wanted 1G or 750M that would be fine too. You can always grow
it again later. Remember it is only shrinking that is a problem. And
the root filesystem cannot be shrunk live by unmounting it. The root
filesystem can only be shrunk by booting to rescue media and working
with it offline. So do not make the root file system *too* large.
# lvextend -L3G /dev/mapper/debian-root
# resize2fs -p /dev/mapper/debian-root
For most random filesystems that need to be larger I tend to use
relative sizing. I will *add* 10G or whatever to them.
# lvextend -L+10G /dev/mapper/debian-other
# resize2fs -p /dev/mapper/debian-other
And that is all there is to it. So you can see that filesystems that
are too small are easy to deal with as long as there is unallocated
space to allocate to them. But too large means some effort to shrink
one first.
Try this on a victim machine first. Get comfortable with the process
before working with the production machine.
Some more docs:
http://wiki.debian.org/LVM
Bob
Attachment:
signature.asc
Description: Digital signature