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
signature.asc
Description: Digital signature