Doing what you want might or might not be possible, depending on what is (and must be) currently mounted, and whether you can boot from some other medium to work around mount problems. Factors to consider here:
- Always keep in mind the distinction between a partition (a simple data structure that defines the start and end point of a chunk of disk space, typically along with other things like a type code) and a filesystem (a more complex data structure that's held within a partition or another container, such as an LVM's logical volume). If you don't already fully understand this distinction, stop now and research it.
- You can increase the size of a mounted ext2/3/4 filesystem, but AFAIK you cannot decrease the size of a mounted ext2/3/4 filesystem. The
resize2fs
utility does this job from the command line.
- To resize a partition, you may have to delete the partition and create a new one in its place. The start and end points may need to be specified with sector-level precision, which
parted
does not provide by default. You need to set unit s
to get this; or you can use gdisk
, which provides sector-level precision by default. (Even gdisk
, though, automatically aligns partitions to 2048-sector values by default, so you may need to adjust alignment with the d
option on the experts' menu.)
- Filesystem-resize operations typically leave the start point of the filesystem unchanged. Thus, if you need to move the start point of a partition, you must do so by using
dd
or some other tool to move the entire contents of the filesystem. Depending on the direction of the movement, this may need to be done before or after you delete the original partition, and the new one may need to be created before or after the move. If the move operation overlaps the original location, you must be very careful about how you do this, lest you destroy some partition data!
- Be very careful about partition and filesystem end points. If you shrink a filesystem and then re-create a new partition that's just a little too small, you can end up trashing important data. I recommend shrinking the filesystem smaller than you intend, creating a new partition, and then using
resize2fs
to grow the filesystem to the size of the new surrounding partition. This procedure minimizes the chances of getting a size mis-match.
- Remember that you may need to reboot after you change the partition table to get the kernel to use the new table.
Because of these issues, attempting to do what you want without the help of GParted or some other tool designed to coordinate partition and filesystem changes can be extremely risky. It can be done, but one slip-up in specifying a sector value can leave you with a disk that's totally worthless. The fact that you're asking for help about this makes me wary about suggesting you even make the attempt; the risk of trashing a production system is just too great for somebody who's never before done this sort of thing. If you have no other option, I strongly recommend you re-create your server locally and practice on the copy before you try it on your remote server.
You might want to consider some alternatives:
- Use GParted -- If you can boot from an external medium, you can use GParted. You say this is a remote server. Many such systems provide a BMC that enables you to attach virtual USB drives and see a virtual console via a Java applet. Using this feature will be extremely slow, but should enable you to run GParted and make your changes much more easily and safely.
- Create additional partitions -- You may be able to shrink one partition and then, rather than move and grow the other, create a new partition. You'd then move data from a subdirectory to the new partition and mount it in place of that subdirectory. This approach basically splits the difference; you must still shrink one partition, but you avoid the need to do the more dangerous and difficult move operation.
- Use symlinks -- You may be able to accomplish your goals by splitting off some files from your too-full partition to the less-full one and then using symbolic links to make them accessible on their desired paths. This is likely to be the safest approach.
- Reinstall -- If you have adequate backup, you could back up the system, re-install with a better setup, and restore your original data.
- Do it on-site -- If you have physical access to your servers, or if you've got on-site help, you (or your help) can do it in person much as you would with a desktop system, using an Ubuntu installation USB flash drive. Depending on how important this is and where the server is relative to you, it might even be worth a trip to do the job.
- Add a disk -- You might consider adding a disk, if that's an option, and moving some of your data to it.
In the future, you might want to consider using Logical Volume Management (LVM), which makes these sorts of manipulations much simpler and safer. LVM has a significant learning curve, but once you've got the basics down, it helps a lot because you need not worry about moving partitions; filesystems are stored like files in a filesystem, so once you shrink one, you can expand another into the free space without changing the start point. LVM also helps you add space in the form of new disks.