Standard disk setup here used to include a 5GB root partition (this has been upped to 10GB for a while now). I’ve just encountered the first machine with this setup to be running out of space on / - mostly this seems to be down to /usr/share.
Unfortunately resizing on-the-fly in this situation is difficult, due to the parted restriction that partitions can only be resized at the end - i.e. their start point must remain the same - which means that I can’t just take space off the front of the next partition along. The disk looks like this:
/dev/hda1 / 5GB /dev/hda2 /local 105GB(there’s swap and so on in there too, but let’s ignore that for the moment).
There is a solution to this, which goes like this (to expand /dev/hda1 by 5GB):
- Resize
/dev/hda2to be 5GB, leaving 95GB spare. - Create a new partition in that 95GB.
- Copy the data from
/dev/hda2to the new partition. - Delete
/dev/hda2. - Resize
/dev/hda1to include that newly spare 5GB which used to be the resized/dev/hda2. - Tidy up as appropriate - all partition labels will have changed so you’ll need to edit
/etc/fstaband possibly your boot loader, before you reboot.
- This only works if you have less than 5GB of data in
/dev/hda2. - You’ll need to be running from a rescue disk or similar if you want to mess around with your
/partition. - Read the
partedmanual before actually doing the above :-)
Unfortunately, my /dev/hda2 partition in the above has rather more than 5GB of data so this plan won’t work. I was intending to dump the data off and then resize; but looking again at the partition table, I’ve noticed the existence of a swap partition between / and /local. Now, the data on this obviously doesn’t matter. So I can delete that partition, expand /dev/hda1 into that, shrink what is actually /dev/hda3 down by the appropriate size, and put in a new swap partition at the end of the disk. This will only get me 2GB, but that should be enough breathing space to be going on with.
All this did also lead me to thinking about the appropriate size for a / partition. 10GB seems like a lot to me… but for a machine with a lot of software, 5GB clearly isn’t enough any more. (There are operational reasons for keeping the root partition separate from ‘data’ partitions.). How much do I really need to allow for futureproofing on boxes I buy now and expect to last 3 yrs? Should I be upping the space to 15GB?
This will depend on how much you need that extra 5 GB (from 10 to 15) for other reasons. In other words, are you more likely to need that 5GB of space for applications and data in / or in /local. Only you have any chance of estimating that.
But I'll try anyway. If you've had 10 gig as your standard size for several years already, and you've only just now gone about 5gig of usage, I'd guess 10 gig will probably be enough for a while to come. Are you likely to need a major OS upgrade in that 3 year window? If you're already keeping up to date then the extra demands aren't likely to push you over, but if you are running a slightly outdated system (we still have boxes running Red Hat AS2 and AS3) then you may well decide to upgrade at some point. In which case, the version you'll upgrade to may even be out already (we may upgrade some systems to AS4) and you can anticipate what would be involved right now.
If these are Debian boxes, sometimes an 'apt-get clean' will free up a few hundred meg, which can give you some time.
What I've been doing for a while now is creating a new partition and moving /usr onto it. It's slightly tricky, in that you need to do any editing before you rename /usr (it's where your editors are, after all).
The ultimate solution is LVM, or something with a bit more flex inherently, but the above works well without learning and testing a whole new set of tools and techniques.
I would recommend useing the gparted live cd. Being a live cd you can resize the partitions as you like. I've used it a bit without any problems, it handles resizing ntfs well so it should be in everyone's toolboxes.
Talking about lvm, are there any guides on how to resize partitions? I have 3 partitions in a lvm volume ubuntu-root, opensuse-root, and my /home partition all ext3 formatted. How do I take some free space from /home and put it on the other partitions?
Here's another approach: symlinks!
For instance, on my Gentoo system, I found I had run out of space on the 10GB / partition a few weeks ago. I looked around and decided that /usr/src (over 2GB) and /usr/portage/distfiles (nearly 3GB) were not crucial to basic system operation, so I moved them into subdirectories under /home/overflow and replaced them with symlinks to the new locations.
This can be done with other things, e.g. /var/lib/mysql (if you're running large databases), /var/log/apache2 (on a busy Web server) etc.
If the problem point is /usr/share, why not resize /dev/hda2, make a new partition at the end, move all the /usr/share contents to that new partition and change that mount point in fstab. I assume /usr/share doesn't hold anything required to boot the system.
daniel:
Reducing a logical volume
Right, it's like Mark said, but i'll tell it a bit more verbose:
1) Check the directory sizes in / and /usr and /opt. You might use a graphical diskspace tool like filelight to easily identify the big maps.
2) > df -h to check partition spaces.
3) Think and think again, and then select a directory of the right size. /usr/share, /opt/kde3, /opt/gnome, it depends. On my desktop system also /usr/share is the bulk (quake4, 3Gigs!).
4) Then, resize /dev/hda2 by -3Gigs (quake4 won't grow, so that's safe).
5) Create the new partition in the empty diskspace and make filesystem.
5) Move over files from quake4 to new partition.
6) Check if your changes work:
# mount /dev/hda3 /usr/share/games/quake4
> quake4
6) Edit /etc/fstab:
/dev/hda3 /usr/share/games/quake4 ext3 defaults 0 0
(or whatever is sane on your system).
7) # mount -a (to mount all) and # mount (to check if everything mounted allright)
This will also work with active software or libs, but then step 7 is a reboot. Of course, the classic way to do this is in runlevel 0 or S (single), jump from runlevel 5 or 3 to 1 with # init 1.
A little note to Lawrence:
Symlinks do NOT always work. At least I've seen programs that wouldn't run if symlinked. And it is easy to foul up (symbolic) symlinks after making them. So I would read the "man ln" before putting important stuff behind a symlink. Besides, you cannot symlink dirs and you cannot make hard links across devices.
I did consider either symlinks, or just moving a specific directory to a new partition, but in the end considered it tidier to resize the full / partition if I was going to be resizing anyway.
Thanks to daniel for the gparted recommendation - parted didn't work for me (complained about unsupported feature of my ext3 filesystem, with no more information) but gparted worked beautifully.
know where your bundled and unbundled software is installing itself to, and you will save yourself lots of grief.
Just give in to the 36GB / partition. Unless you like gtar -c -f - | (cd /newroot; gtar xpf -)
and moving the bootblock every 4 months.
Solaris 11 is up to a minimum 10 GB / for a full install. I assume SUSE and the rest are similar by now...
I roll out a couple of Linux servers a month. Usually a samba server and a rsync snapshot backup server. Remote site with no technical people on site. CentOS 4. Here is my current partitioning scheme.
/boot 250MB ext2
/ 10GB ext3
Swap 2x RAM
/home 10GB (20GB on snapshot) ext3
/export (samba partition) remainder of disk ext3
The main point of partitioning is to separate easily reloadable system files from irreplaceable user data (home and export in this case) The 10G root is large enough to go for years even with automatic updates, in this scheme. If not, it easy enough to repartition and reinstall CentOS (backup /etc and make list of packages) without touching user data. Parted definitely is too limited to help.
For your original problem:
You want to add 5GB to hda1. Lets call the desired addition L (so L is 5 here).
hda2 is M GB in size (your M is 105) but contains more than 5GB. Lets say it contains N GB.
You're okay, as long as L + 2N < M. Proceed like this:
Resize hda2 down from M GB to (L+N) GB. This frees up at least N GB (maybe more, but N is enough).
In the newly freed space, create hda3.
Copy hda2's contents into hda3.
Delete hda2. This frees up (L+N) GB.
Extend hda1 by the desired L GB.
Recreate hda2 in the remaining N GB.
Copy contents from hda3 back into hda2.
Delete hda3.
Extend hda2 as far as possible to reaquire the N (or more) GB used by hda3.
Or, just get an external disk drive to hold the temp copy of hda2...
MC: yep, that's very similar to the scheme I use (although with NFS-mounted /home). Good to know that 10GB has been sufficient for you for a good long while; I think it really should be here!
bobmon: You're correct about the critical relevant sizes; unfortunately in my case more than half of the second partition was full, so no room for the moving around you suggest. I could have chucked it all onto another disk on another machine & then back again, but that does take *time*. I've found an extra 2GB which will do for the moment.
thank u for this