Linux noob question regarding full / partition
Background: I started daily driving Linux (specifically Mint) several months ago and for the most part it's been great. Some weird hiccups occasionally but nothing I can't handle/deal with. When doing my research to set the system up for the first time, I decided to go with 30GB for the / partition and ~220GB for the /home partition (the other half of the drive is for Windows 11 and the various essential tiny partitions). For a while this seemed to be fine, but lately I've been starting to get warnings when performing software updates via the Update Manager that the / partition is running out of space. I think it peaked at maybe 90-95% full a few weeks ago, at which point I started doing some research and cleaning up a bit (apt autoremove, deleting old logs and kernels, etc). I was able to claw back ~4GB and kick the can down the road, but now the warnings have returned and I'd like to handle this properly. I'm working from the assumption that I simply made the / partition too small and intend to double it by giving it some of the Windows space.
My question: How do I know if this is expected or if I've been doing something wrong? Is 30GB indeed too small on modern Mint, or should that have been enough? I know it partially depends on what all I actually do with the computer, but I really don't have very many applications installed (aside from defaults of course) and only four of them are Flatpaks, which I read tend to be larger. If it helps, the Disk Usage Analyzer reports that within /, /usr is taking up 13.2GB (55%), /var accounts for 9.1GB (38%), /opt is 1GB (4%), and everything else is <1% each.
Thanks in advance!
Potentially unhelpful answer: I've used various Linuxes (Linices?) for quite a lot of years and haven't ever bothered putting
/homeon a separate partition. I know that's not really what you asked, but it seemed worth mentioning just as data point for you and potential option for avoiding the problem entirely.Pre-planning how much space I'm expecting system files and applications to use sounds like a difficulty that's probably better avoided, but as a finger in the wind estimate I would say 30GB is fairly small given that even some python libraries can be >1GB nowadays.
I don't remember my exact thought process from months ago, but I think I saw it recommended to separate
/and/homeso that switching distros or reinstalling would be easier. My understanding was that you can wipe/to do either of those things and leave all your user files intact. I think?Yeah, there’s a valid argument for doing it and it’s by no means unheard of - I can especially see why a more new-Linux-user focused distro like Mint would recommend keeping that separation.
I just don’t personally think the trade off is a particularly good one: I’d want backups of all my data anyway, which makes the advantages pretty much moot, and if I were doing anything like a major reinstall that’s going to blow away a system partition I’d really really really want an additional temporary copy of those files on a USB drive that’s physically unplugged anyway - so that when I fat finger a command and wipe the wrong partition on the internal drive I know I can just copy it all back later.
I guess what I’m saying is that I’m too precious about my data to trust a partition to isolate it safely anyway, so I find it easier not to have to worry about balancing partitions at all.
That does make sense. If nothing else it's a reminder that I really need to set up backups again; I used to use Google Drive to back up my machine, but I'm in the (very slow) process of ditching Google so I haven't done that for my new setup. Aside from Timeshift I don't have any automated backing up happening.
It's an understandable philosophy, but it's not that much easier than just backing up your home directory in any other way and reinstating it after a re-install. Personally, most everything in my home directory bar the downloads is synced between all of my devices using Syncthing, and I've never bothered with splitting home out into a new partition.
I use a single logical partition but keep /home and / in separate btrfs subvolumes.
If you're going to re-partition anyways, I'd recommend looking into btrfs via a distro that supports it out of the box like openSUSE. I think switching to btrfs from ext4 has been one of the biggest level ups of my home computing flow and now I would never live without it. Transparent compression is amazing, snapshots are amazing, btrfs send/receive w/ deltas is amazing, being able to browse the file system of all my backed up snapshots is amazing, I could probably go on.
Flatpaks are pretty space hungry because each one might depend on a different FreeDesktop environment so that's like 1 or 2GB per app lol...
30GB is still very reasonable for a non-GUI system. Lots of space for user files too. But for GUI... each program can be pretty big. If you have something that depends on Gnome, depends on GTK+, something that depends on KDE, depends on Qt... then you have a lot of dependencies that can be large in aggregate. So maybe not that different from Flatpak in the end.
I would say 50GB is reasonable for a GUI system. But if you use something like Btrfs subvolumes or LVM partitioning then it's not so painful when you realize that you need slightly different volume allocations
My / partition is 50GB and that's been fine for me on a very old and very multipurpose machine with all sorts of crap installed, but I wouldn't go much smaller than that.
I'm assuming Mint set you up using ext4, so you can pretty safely resize it if you need to. Gparted is the tool I'd use but there might be a friendlier one out there.
Obviously don't resize partitions containing data you can't afford to lose, but it's a decently safe operation and I've done it plenty of times without an issue. Worst case you have to reinstall but you're probably looking at doing that anyway if / is out of space.
Wait, so can I just resize it or not? I think I'm missing something you're saying here.
You can resize it. In the unlikely event something goes wrong with the resize, you will probably have to reinstall your system. If you don't resize the partition, you're going to have to reinstall and recreate your partitions anyway. So you might as well try.
I didn't want to say "resizing is 100% safe and will definitely solve your issue" because that's not entirely true. Resizing partitions does carry some risk of data loss but it's very small. I haven't ever had a problem with ext4, but have with some other filesystems.
Right, okay. I think I just read the two statements I quoted as conflicting with each other. Thanks.
You can also free some space from /var with
apt cleanbut as you say that kicks the can down the road if you are installing a lot of packages. My system with years of cruft is up to about 40gb in root. Resizing the partition is one option, though if you are dualbooting with windows a new 2nd hard drive is probably the best option.Yeah, ideally I'd have two separate drives for this setup, but it's a laptop and short of lugging around an external drive I don't think there's really a way to have that. Aside from doing some serious hardware modding, maybe.
Main Menu ('start button' menu) > Disks > click on your disk > click on the 'Gears' icon > click 'Resize'.
For safety sake, please backup anything you care about off that disk as an insurance policy if somehow you bork your install and have to wipe/reinstall. Unlikely, but good to take precautions.
You can get an idea at a glance of what's taking up that space using something like qdirstat or kdirstat, which recursively visualize which subtrees occupy most of the partition.
I second Greg's advice but I'd go further - for a personal machine, partitioning is a total noob trap. Distros putting it in the default path of their installer is a mistake. And it's easy to see this with a very quick cost/benefit look.
Q1: What benefit do you get from partitioning the drive(s) of a personal machine?
A: Nothing. Dedicated hobbyists, or people who research filesystems, may gain some use from partitioning. But normal users (even most linux power users) get no benefits from partitioning.
Q2: What costs do you incur from partitioning?
A:
There are more costs, too, but you are personally encountering those right now.
Now, for a server, partitioning can be very useful. But that's not your use case.
After some more research, I'm starting to think you're correct. Back when I was setting the system up, it seemed like it was just a given that you were supposed to create some number of partitions for things like
/and/home, so I spent most of my time looking to get an idea of an appropriate size for those. Kinda seems like I should have been questioning why you would do that in the first place instead. I initially thought I might be trying out distros once or twice a year until I found one I liked, but that doesn't seem likely anymore. Making distro switching easier was the main benefit of a separate/homethat I saw mentioned, but if I'm not doing that, then I suppose I don't really have a good reason for it to be set up that way.I guess I'm just lucky that I had fun learning something new and didn't break anything in the process!
If you have a filesystem that supports snapshoting + snapshots setup, you might want to purge old snapshots and just keep the more recent ones.
You can use something like filelight to visualize what's using the most data, and that'll give you hints about what you might need to clean (E.g. Old docker images, containers, volumes).
Yeah I meant to mention in the OP that my Timeshift snapshots are saved on
/home. Clearing those was suggested a lot when I was researching this a few weeks ago but it's not relevant here.AFAIK, unless you've gone out of your way to move them, snapshots stay on the disk/partition as the filesystem they correspond to. So if you're snapshotting
/it's take up space on the 30GB partition.If you're just snapshotting home then you're correct, that isn't the problem
I'm just snapshotting
/, but if I go into Timeshift and open the "Location" tab, under "Select Snapshot Location" the partition containing/homeis selected. At the bottom of the window, it says "Snapshots are saved to /timeshift on the selected partition." This appears to be confirmed by the file explorer.Is changing the location selection to something other than default what you mean by "going out of the way to move them"? If so, then yeah, I did that.
I was off base, as I didn't understand that timeshift could do more than CoW snapshots like streblo said. My understanding though is if you are operating in btrfs mode it's still creating CoW snapshots.
Anyways. Just to put this to bed, can you run
sudo btrfs subvolume list -s /? If that returns nothing, then there are no btrfs snapshots eating up space on the root partition.Edit: I should point out that this only matters if the root partition is formatted as btrfs. If it's ext4 or whatever then this all goes out the window and is not a issue
Yes, it's confusing. I dislike Timeshift even calling them snapshots, because anyone researching "linux snapshots" is going to be reading about all the features of CoW snapshots when really what their getting is a plain old copy of their data.
@Kind_of_ben can I ask what is the purpose of your snapshots of
/? If both partitions are ext4, those "snapshots" are full (near 30 GB) copies of your '/' partition. Personally, I don't think it's worth backing up the system parition for rollbacks without lightweight snapshots, you can just as easily back up a list of your installed packages as well as /etc/ if you've made conf changes and restore from a fresh install and that information.As for your space issues, I'll echo what @text_garden said;
du(or qdirstat/kdirstat for a gui based tool) should help pointing you in the right direction.For the space analysis, I've just been using the included Disk Usage Analyzer. Are qdirstat and kdirstat significantly better? I don't think I really need that much out of whichever app I use; DUA shows a graph breakdown and you can browse through it which seems good enough for me.
To back up stuff that's critical to the system running properly, right? That's what I found to be recommended when I was setting this up back in February. I guess I don't really know what parts of
/are and aren't necessary to back up. I'm not hurting for space in/home(where the Timeshift backups are saved) but I suppose it would be nice to not have so much of it taken up by backups. Though, according to Timeshift, only one of the "snapshots" is the full directory; the rest are incremental (verified by examining the sizes).Nope, you're good.
These snapshots are on disk, so they don't help you in cases of disk failure. Where they are useful is after an update if something is broken or isn't working correctly you can roll back. If your system isn't bootable you'd have to do this via a live USB. This can definitely be convenient but it's important to remember that it's probably not all that likely, doubly so if you're not using a rolling release distro. Another option you have is to just reinstall your OS. Everything in / is somewhat fungible, it will all be replaced in a reinstall. The only thing that you'd need to completely replicate your install is a list which packages you've installed as well as any configuration changes you've made in /etc and things like /etc/fstab. If you wanted, you could back up the output of
apt list --manual-installedas well as all of /etc and be able to recreate your system with much less space required than your current approach. You would just boot into a live usb, reinstall to /, and then copy your backup of /etc over. Then either chroot to reinstall your packages or just install them after rebooting.OK, that's good to know, it's kind of a "CoW snapshots at home" approach then. If you're happy with it, there's nothing wrong with that approach but yea you do eat the space. How btrfs and other CoW (copy on write) filesystems work is that there is a section on your disk for data and a section for metadata. When you make a copy of some data only the metadata gets updated until you actually make changes to the copy. So a snapshot of / or any disk is effectively instant and you'll only eat the space for the actual diffs as your system gets updated. Similar to your backups folder but without having to have the 30GB "base"
It's my fault for not spelling out that I was taking about filesystems that support atomic snapshotting out of the box like BTRFS and ZFS and then assuming BTRFS when Timeshift was mentioned.
But yeah, Timeshift probably should be calling them backups instead of snapshots. Rsync backups can't guarantee the filesystem hasn't changed during the backup. It's hazy since Timeshift supports both BTRFS mode and Rsync mode.
Yeah, both partitions are ext4. Thanks for your effort though!
This is true for CoW snapshots but OP is using Timeshift which can be used by btrfs but I believe the default is plain ol' rsync and ext4 under the hood. So they're not really what you think of as snapshots.
Coincidentally, I had to clean up my Manjaro root folder this morning--in my case the main culprit was some log spamming, but also I've been lazy about cache clearing and removing orphans. (I've also allocated 30 GB, another coincidence.)
I used this link in the Manjaro forum--it's probably not exactly what you want, but it may help you find a similar post on the Mint support forum. I found the info on limiting log sizes especially helpful (although I also solved the cause of the spamming, not sure how, exactly...)
I tend to run separate partitions for
/,/var,/root,/etc, and/tmpthrough LVM, typically in ext4 because I'm a basic bitch. LVM is nice as I can shrink/expand file systems live, no need to shut down/boot from a live ISO/use another machine. Namely because if I accidentally fill one up, it's typically easier to find/fix the problem that way, without my whole disk being full. I also tend to keep some free space in reserve of the LVM so I can expand the problematic partition while I problem solve, if needed. Highly recommend thencdutool for helping troubleshoot, as well. You can use the-xflag to avoid crossing partitons if you just want to examine one partition.I what you seem to have done. I use Arch, and it was a learning process getting it to how I wanted. But it was much easier "starting over" without having to redo tweaks and touches that I really did enjoy (custom bash prompt, i3 layout since I don't use a DM, etc.). I also have a "spare" drive (partition) where I keep all my other stuff, and also symlink my Documents, Downloads, etc. to that as well, which adds an extra layer of separation. Granted, symlinks have kind of bit me in the butt before, but those were mostly due to linking my Games.
This has saved my butt a few times. I had a m2 that somehow went bad (everyone said it was on my end, blame linux, etc... but turns out, it actually crapped out about a year after I got it), and recently I ran into the same issue as you after almost 5 years of tweaking and sometimes reinstalling, so partitioning was simple. And I still have that disk attached and can boot up one of the partitions if I realized I missed a file (as I did not copy things over to keep the new drive cleaner).
Currently, I am using the following, with the old Spare partition unmounted. I left all that intact on this drive since it's 4x larger. (And I also keep a small Games folder because it makes me play the games I have before installing more, or even worse, buying more and not playing any of them.)
nvme1n1 259:5 0 1.8T 0 disk /home/x/Gamesnvme2n1 259:6 0 931.5G 0 disk├─nvme2n1p1 259:7 0 500M 0 part /boot/EFI├─nvme2n1p2 259:8 0 100G 0 part /└─nvme2n1p3 259:9 0 831G 0 part /homeEdit: I was curious, so here are my directory sizes (via du -h --max-depth=1 | sort -hr):
1.2T ./home11G ./var9.6G ./usr493M ./boot391M ./dev100M ./opt8.9M ./etc2.8M ./root1.8M ./run