0

I have had these questions for a long while, so I hope this post won't be closed.

gparted shows the current partitions on my hard drive:

enter image description here

When I partitioned my hard drive two years ago,

  • I didn't know how to resize a partition. I still don't (it is dangerous to try, and I don't have another external hard drive for backup, and I don't want to risk loss of files on the partitions) and wonder if you could provide some concrete commands (e.g. using parted and optionally gparted ) when answering the following questions.

  • I didn't know how to design the partitions so that their sizes could be flexible to change. So I wonder if you could suggest on how to improve the partitioning?

Questions:

  • Is it correct that we can resize a partition only by changing the end of the partition, not its beginning, regardless of which tool (parted or not) to use?

    Is it possible to merge two partitions, without removing them first and creating a new one, regardless of which tool (parted or not) to use?

  • Is there a recommended ratio of used over total size for the / partition? Specifically, for the / partition (/dev/sda3), its used size hasn't been changed drastically over the past two years, and is now only 21GiB. If I could restart partitioning from the beginning, how much size do you recommend me to specify as the total size for the / partition?

    Is there a recommended ratio of used over total size for the /home partition?

  • How can I move some of the largely unused space of the / partition (/dev/sda3) to the /home partition (/dev/sda4)?

  • I don't remember why I left a 93GiB unallocated space where it is. I guess I wanted to allow both/home and / partitions to get more space from the unallocated space if either of them needs to.

    Is it possible to add the unallocated space to the /home partition (/dev/sda4) and how?

    Is it possible to add the unallocated space to the / partition (/dev/sda3) and how? (I don't really need to do this, but just as an example to enlighten me of what partitions can be resized and how to)

Thanks.

closed as too broad by Stephen Kitt, Stephen Harris, Kusalananda, Jeff Schaller, Rui F Ribeiro Feb 19 at 13:50

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • create a big sparse file as large as your disk (with dd seek), duplicate the partitioning of your disk on it, and practice on it until you understand how the thing works. You'll find an example in a recent answer of mine. – pizdelect Feb 18 at 17:52
  • @pizdelect Is it unix.stackexchange.com/a/500200/674? – Tim Feb 18 at 18:26
  • Try to do this until you understand how storage is stacked in the Linux system. You can get an answer to all these questions, but that's not more useful than hire someone. – 炸鱼薯条德里克 Feb 19 at 2:09
2

I suggest you to resize root / partition, then make a mountpoint in ~/, I'd use the Downloads folder as it's volatile and usually quite big.

then set fstab to mount the new partition made from 'freed' space in ~/Downloads

move the current content of Downloads to the new partition

Restart the system

2

I'll try to answer your questions to the best of my knowledge. I only know the use of GParted however.

Please take backup of your data before doing any re-partitioning.

Please use a bootable GParted distro or equivalent to do this, as you need to un-mount the partitions before proceeding.

Answers:

Is it correct that we can resize a partition only by changing the end of the partition, not its beginning, regardless of which tool (parted or not) to use?

If there is unallocated space on both left and right of partition, you can resize on both directions using GParted.

GParted demo animation

Is it possible to merge two partitions, without removing them first and creating a new one, regardless of which tool (parted or not) to use?

AFAIK, you have to delete one of the partitions at least and then merge to the other.

Is there a recommended ratio of used over total size for the / partition? Specifically, for the / partition (/dev/sda3), its used size hasn't been changed drastically over the past two years, and is now only 21GiB. If I could restart partitioning from the beginning, how much size do you recommend me to specify as the total size for the / partition?

You are correct in observing that used size of / partition usually does not change much over time. There can't be a recommendation however, that fits everyone's need.

One needs to see the maximum size their OS uses after all programs are installed, and then add some buffer for future needs (say, 50GB more) and then partition accordingly.

Is there a recommended ratio of used over total size for the /home partition?

Again, each to their own. I personally keep a / and swap, and give rest of space to home. My reason being one can use folders to organize data rather than splitting the disk into partitions.

How can I move some of the largely unused space of the / partition (/dev/sda3) to the /home partition (/dev/sda4)?

Be very careful here. Resizing the / partition may (will?) result in you system unable too boot. I think if you want to resize /, be prepared to do a full install of the OS.

I don't remember why I left a 93GiB unallocated space where it is. I guess I wanted to allow both/home and / partitions to get more space from the unallocated space if either of them needs to.

Safely, you should be able to merge it with the /home partition (after unmounting /home). Merging with / is not possible presently as they are not adjacent to each other.

Is it possible to add the unallocated space to the /home partition (/dev/sda4) and how?

Yes. See above.

  • Thanks. Could you give some examples of not uncommon programs that can take up a lot of space in / and how much? – Tim Feb 20 at 3:05
  • Welcome, depends on user. For me they are LibreOffice, the browsers, and the package cache that accumulates over time for Arch. Use Disk Usage Analyzer to see disk space distribution. – Arslan Farooq Feb 20 at 7:20
2

Is it correct that we can resize a partition only by changing the end of the partition, not its beginning, regardless of which tool (parted or not) to use?

Filesystems generally expect that the underlying storage is contiguously addressable, i.e. when the operating system says that a particular disk/partition/LVM logical volume/whatever container is X blocks in size, the filesystem assumes that first block is #0, the last one is #(X-1) and there are no unusable holes in between. As a result, a mounted filesystem can really grow only by having more blocks added to the end, and shrink by having some blocks cut off from the end.

For an unmounted filesystem, the amount of surgery you can do is only limited by how well you (or your utility program) understand the structure of the filesystem that is being modified, and the requirement that the result must again look like a valid filesystem when you're done.

For most partition management utilities, moving the beginning of a partition involves moving the entire partition as a block to the new beginning point, then resizing as necessary at the tail end. A really clever utility might be able to move some files to make space for necessary metadata structures, and then reconstruct the filesystem metadata in a location that corresponds to the new beginning of a partition without moving all the blocks, but such an operation would be extremely risky and would probably cause hopeless filesystem corruption if interrupted.

Is it possible to merge two partitions, without removing them first and creating a new one, regardless of which tool (parted or not) to use?

It depends on filesystem(s) involved, but usually not; the standard method would be to move the files within the partition with less data into the other partition, then delete the now-empty partition and use the freed space to extend the other partition. If there is not enough free space to do that in one pass, it gets tricky.

Is there a recommended ratio of used over total size for the / partition? Specifically, for the / partition (/dev/sda3), its used size hasn't been changed drastically over the past two years, and is now only 21GiB. If I could restart partitioning from the beginning, how much size do you recommend me to specify as the total size for the / partition?

Since your experience over two years shows there's not much change, I'd aim for something between 33% .. 66 % usage level, so anything between 40 .. 60 GiB total size, to allow for plenty of space for upgrades, software installations and the like. Then again, I'm very familiar with Linux LVM so I prefer to use it, as it provides much more flexibility than traditional partitions. (Of course, there is a learning curve.)

Is there a recommended ratio of used over total size for the /home partition?

It depends heavily on what kind of files you handle: if you edit HD/4k videos, you'd have a huge free workspace for projects. Filesystem-wise, I've heard that most filesystems work best when less than about 80% full.

How can I move some of the largely unused space of the / partition (/dev/sda3) to the /home partition (/dev/sda4)?

This will be a multi-step operation, and you'll have to have the filesystem unmounted for at least the 2nd step, so you'd have to boot from a Live CD or other removable media to do it.

Step 1.) Shrink /dev/sda3 to the desired size. (gparted may be able to do this while the filesystem is mounted.) Step 2.) Move the now-smaller /dev/sda3 "to the right". This will definitely require the filesystem to be unmounted, and since it's your root filesystem, an alternate boot media is required. Step 3.) Extend /dev/sda4 into the now-freed space.

I don't remember why I left a 93GiB unallocated space where it is. I guess I wanted to allow both/home and / partitions to get more space from the unallocated space if either of them needs to.

You could unmount your /home, then use gparted to move it "to the left" so that the unallocated space will be between sda4 and sda3. Extending sda3 would still be a "boot from removable media, move sda3 left the necessary amount, then extend its tail end" operation.

What if you had used LVM?

Then you most likely would have set up a volume group with just a single LVM PV in place of both sda3 and sda4, and two LVM LVs within it. You could resize them within the bounds of available space. As a result of resizing operations, the LVs on the disk might not be fully contiguous within the PVs, but as long as you don't keep fiddling with the LV sizes too much, a small number of discontinuities is not a problem in practice. (You might have your original allocation for /home, then your root filesystem, then another piece of /home as you found out you needed more space. The filesystem drivers will see a contiguous range of blocks within the LV; the logical volume manager will deal with the fact that physically there is your root filesystem somewhere in the middle.)

Assuming that the currently-unallocated space was used by something else originally, you could now create another partition out of it, make it a LVM PV, then add that PV into your existing volume group. Then you could use it to extend any of your existing LVs, or to create new LVs as needed.

And when it's time to move your data from an aging disk to a new one, you'd just partition your new disk with any necessary partitions for booting + ideally just one big LVM PV. Then add that PV to your existing volume group, and you'd be ready to move your data to the new disk with a pvmove operation. All that while your OS is running. (As a nice side effect, pvmove will make all your LVs physically contiguous while moving them if there's space to do so - and when moving all your data to a new disk, there certainly is.)

When the pvmove operation is complete, you'd just need to drop the old disk out of the volume group, re-install the bootloader to the new disk, and you'd be ready to physically remove the old disk.

With LVM, you'll come to think of your data as a sort of viscous liquid that you can pour from one PV container to another at will. If one PV is getting full, it's no problem to grab another PV to hold the rest of it as long as both belong to the same volume group.

  • Thanks. (1) Could you give some examples of not uncommon programs that can take up a lot of space in / and how much? (2) Is my 20G usage in / a typical case for personal usage? Could you give some examples of common usage sizes in /? – Tim Feb 20 at 3:07
  • Thanks for the LVM suggestion. I haven't used it. Right now I have a single partition for root and home, can LVM help to separate them for protecting one from the other? Or do I have to repartition my hard drive into one partition for / and one partition for /home? See askubuntu.com/questions/1119975/… – Tim Feb 21 at 0:12
  • Unfortunately, adding LVM to an existing system can be a complicated operation, especially so if you don't have much unallocated space. When using LVM, LVs pretty much take on the role of partitions, but with added flexibility. – telcoM Feb 21 at 5:33
  • (1) Does my hard drive not have much unallocated space? What is the criterion by which you mean that? (2) Should I re-patition my hard drive into two partitions / and /home, or can I use LVM over the existing single partition to create separate volumes for / and /home? – Tim Feb 21 at 5:46
  • The problem is that you cannot just add LVM to an existing non-LVM partition. You would have to shrink your existing partition as much as you can, then create a new partition to be used as a LVM PV, create the LV(s) you desire into it, copy the data, update your boot configuration and initramfs to be aware of LVM, then boot to the LVM version of the system, and then either repurpose the old non-LVM partition as a second LVM PV on the same disk and add it to the existing VG, or remove it and resize the only LVM PV on the disk. – telcoM Feb 21 at 5:57

Not the answer you're looking for? Browse other questions tagged or ask your own question.