Comments on: Disk Space: The Final Frontier

By: eperry

eperry — Wed, 30 Nov -0001 00:00:00 +0000

Step 9 I personally believe that you should not remove the directory until you reboot at least once.

To be safe it would be better to do the following
mv /usr /usr1
mkdir -p 755 /usr

then after step 10 (the reboot) just clean up after your self
rm -rf1 /usr1

By: palov@bio.bas.bg

palov@bio.bas.bg — Wed, 30 Nov -0001 00:00:00 +0000

I\'d better mount the already populated \"new\" /dev/hdc1 over existing /usr, after step 7 and make some checks, and then fix /etc/fdisk in step 8; then I will mount /dev/hda1 on a temporary mount point, e.g. /mnt/tmp and there will remove /mnt/tmp/usr/* - cause I\'m not sure how happy will be a running system with an empty /usr between steps 9 and 10! Maybe, before removing the old /usr/* I\'d make an \"rsync -avn /mnt/tmp/usr/ /usr/\" as a last check?

Regards,

Petko

By: dbayer

dbayer — Wed, 30 Nov -0001 00:00:00 +0000

I\’m with eperry on this one. If something were to go wrong, it makes for a much quicker & easier fix, while at the same time adding only slightly to the work required to add the disk.

By: symeonb

symeonb — Wed, 30 Nov -0001 00:00:00 +0000

Interesting perhaps, but nowhere in the title or resume does this mention it is infact for a vbox ! ? so perhaps not all that useful for many linux admins.

By: dragonwisard

dragonwisard — Wed, 30 Nov -0001 00:00:00 +0000

@symeonb: I agree, it seems misleading. However I think it\’s implied that the same technique he demonstrates with virtual disks could be replicated in meat-space with physical disks.

By: cldavisjr

cldavisjr — Wed, 30 Nov -0001 00:00:00 +0000

Great article! Simple and straight forward. Many different scenarios exist for this problem. Your example of it happening with a VM is appropriate. Once adding a new \"disk\" for your VM your solution follows and given no errors it is simple and easy to verify. With a VM (at least ours) you can take a snapshot of the current VM image and should a problem arise after editing the /etc/fstab or related to the newly created partition you can reboot into the backup VM image, mount the new partition on a temporary mount point and troubleshoot.
How about an additional article on the new file system features that allow dynamically growing a partition in a non-VM environment? They are a boon to the Linux community and have added to Linux\' ability to stay at the top of the server world.

By: knightperson

knightperson — Wed, 30 Nov -0001 00:00:00 +0000

While a reasonable option in some situations, this solution only works if it\'s a system that can be shut down while you do the maintenance. If you don\'t boot to single user mode, there\'s the possibility that the old and new copies of /usr will end up different, or if you use mv then you will have parts of the OS not working when their /usr files suddenly disappear. In my opinion, a better solution, although it requires some forethought when building the machine, is to use LVM. With LVM and modern filesystems (most of the ones newer than ext3 can do this), you can do this all without rebooting the system or even unmounting anything.

Going from memory, the steps would be
1) create the new partition with a hex ID of LVM physical volume (sfdisk or similar)
2) Put an LVM physical volume on the partition (pvcreate)
3) add it to the LVM system (vgchange, I think)
4) extend the volume group used by / to include the new physical volume (lvextend)
5) resize and expand the root filesystem (depends on the filesystem)

It\'s still a good idea to have your partitions separated when you build the system, of course, but LVM gives you much more flexibility in growing their sizes when necessary.