Critique my partition sizes
 

A UEFI system with 24GB, installing Fedora latest-greatest 29.

/swap 8GB
/var 24GB (I've always put tons of things in /var/tmp, plus /var/log and messages)
/boot 1GB
/boot/EFI 1GB
/home 631GB
/ 266GB

The size of / seems wasteful. On a default system, a handful of GB should suffice. Of course, you know better what you plan to install.

On the other hand, swap might be too small if you want to save crash dumps or hibernate, and you could be a bit more generous with /var as well. Databases, logs, virtual machine images etc live on /var.

All that depends so much on the actual applications you will install and run that outsiders’ comments are fairly useless.

Agreed - totally pointless request.

I'll second this. I commonly give the root partition about 25 GBs. I recently did the df command on my computers and found that the root partition, which includes /var, on every one was about 50% full.

I don't have a /boot partition on any of my machines. Your mileage may vary.

Unless you plan to use hibernation, in a computer with 24GB RAM (which is how I interpret your somewhat elliptical statement), you could probably get away with less /swap. This machine on which I type has 16GB RAM and a 4GB swap partition, runs at least two VMs almost all the time, and is otherwise heavily used, hardly uses /swap at all.

You are right about /var

I thought about making / a lot smaller but from past experience I know that it will be impossible to resize / as it needs to be contiguous versus (/home, and such that can be resized in LVM) From what I know if /boot or / is not adequate, essentially you will end up rebuilding the system to expand these logical volumes.

I am also not really certain if I should make /usr a separate LVOL. I used to do so but not really sure it's needed in my configuration. Nobody seems to do it anymore.

Forgot to mention the SSD size is 1TB

I do not plan hybernation. The machine is SSD and boots in a nanosecond, so that's never an option.

I did shrink /, increase /var and added /tmp


/var always seems to run out of space more than anything, it's the only dynamic filesystem. I made it 40GB

/ is important for /usr or /usr/local where a lot of stuff gets installed and it grows kinda heavy also over the years.

/tmp is good to have separate, I made it 25GB just in case, prob too much.

The only size / partition on which I have (several) F29s installed is 5600MB, and only /home and swap among LSB are separate partitions. Triple digit GB / is thoroughly wasteful. Even for BTRFS with snapshotting (where supported), 40GB for / is typically recommended to be adequate, so half that for EXT4 should be amply more than adequate for someone using separate filesystems for /boot, /var & /tmp.

I did not make a special filesystem for /opt or /usr so all that is encompassed under / now, which I made 80GB. I suppose I can always resize it.
I love LVM.

All of my systems have a max of 15g for /, 2g for swap. Rest of space is usually dedicated to a /data partition which I symlink the appropriate folders into my /home/"$USER"/ folder. Depends on use case though. For me I see no reason to have separate partitions for everything.

I understand it depends on the size. 1TB will be much different than 80GB or 300GB.

Complex solutions can lead to complex problems. I tend to have just one partition and all on it. SWAP is a FILE, not a partition. Back in the day /boot/ was it's own thing to protect it from kernel panics and hard crashes. And /var/ was it's own thing due to the frequency of writes. And swap was it's own thing and put near the center of the "physical" spinning storage so it was always only 50% at worst the distance to access it. These days storage is not as dependent on things physically moving. And storage is cheap. Let it wear out and throw in another device. It's cheaper than the labor to setup a complex solution to extend the life of what was once expensive hardware. Unless each partition that you setup is it's own device for speed, you're just making life hard on yourself.

So, your choice is to have the complexity and time consumption in failure evaluation and in backup/restore/media writing and management. Mine is to have it up front, making the backup and restore chunks fit smaller media spaces, which each take less time to write, and take less time to isolate what went wrong. Those who KISS to start get their complexity when the HD fails and they never backed up anything. Complexity at some point(s) is unavoidable.

The idea behind making /var a separate mount point is because /var grew, it was dynamic. You did not want to overwhelm the rest of the filesystem with /var/log messages (or syslog in other flavors of Unix). Can you imagine a 300MB hard drive and /var that was not separate, I had one in my first Unix machine back in the day. Even an 80GB drive needed its own /var. They were relatively tiny back then.

/usr/local always grows due to software installed there.

/tmp you want its own mount point due to well, temporary stuff being written there. I know, not much of an explanation.

On the systems I've admin'ed, production machines, I have never seen /home grow, it's the least used filesystem. It's always /opt or /usr or /var due to software being installed there and generating logs. Of course on a "home" computer, /home might be very relevant, kind of equal to "My Documents" on a Win box.

What I've seen in the past is / (root) very small and all other filesystems specifically defined such as /usr, sometimes even /usr/local, always /opt and such.

My very first Linux bot I got, had everything under root "/" and I had no issues with that either. That was in late 90s and I just cannot remember the size of the HDD, probably 40GB but not entirely sure.

When your backup strategy requires a thesis to implement, you're doing it wrong IMO.

In my use case, I do have backups. Although more in that I use a new storage device and start over every quarter-ish. And most of my "media" is on storage that doesn't involve an OS installation on the same device. 1TB devices are < $100, have been for more than a decade. 32GB sticks have been $10-ish for a few years now. And that's the OTS retail price. If you're counting MB's when GB's are pennies on the dollar, perhaps it's time for next generation hardware.

For most that I know dealing with failures, the software sucks, the hardware sucks, or someone smite-ed you. The solution for which is get newer hardware, refresh the software and drive on. Most everything else is out of your control anyway. If failure is that big of an issue, have redundancy and use it, while you figure out what failed and why. At which point time is less of an issue because you're NOT offline.