24
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 21 Dec 2024
24 points (92.9% liked)
Linux
48655 readers
516 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
You can do it but I wouldn't recommend it for your use-case.
Caching is nice but only if the data that you need is actually cached. In the real world, this is unfortunately not always the case:
Having data that must be fast always stored on fast storage is the best.
Manually separating data that needs to be fast from data that doesn't is almost always better than relying on dumb caching that cannot know what data is the most beneficial to put or keep in the cache.
This brings us to the question: What are those 900GiB you store on your 1TiB drive?
That would be quite a lot if you only used the machine for regular desktop purposes, so clearly you're storing something else too.
You should look at that data and see what of it actually needs fast access speeds. If you store multimedia files (video, music, pictures etc.), those would be good candidates to instead store on a slower, more cost efficient storage medium.
You mentioned games which can be quite large these days. If you keep currently unplayed games around because you might play them again at some point in the future and don't want to sit through a large download when that point comes, you could also simply create a new games library on the secondary drive and move currently not played but "cached" games into that library. If you need it accessible it's right there immediately (albeit with slower loading times) and you can simply move the game back should you actively play it again.
You could even employ a hybrid approach where you carve out a small portion of your (then much emptier) fast storage to use for caching the slow storage. Just a few dozen GiB of SSD cache can make a huge difference in general HDD usability (e.g. browsing it) and 100-200G could accelerate a good bit of actual data too.
According to firelight I have 457 GiB in my home directory, 85 GiB of that is games, but I also have several virtual machines which take up about 100 GiB. The
/
folder contains 38 GiB most of which is due to the nix store (15 GiB) and system libraries (/usr
is 22.5 GiB). I made a post about trying to figure out what was taking up storage 9 months ago. It's probably time to try pruning docker again.EDIT:
ncdu
says I've stored 129.1 TiB lolEDIT 2: docker and podman are using about 100 GiB of images.
This would be the first thing I'd look into getting rid of.
Could these just be containers instead? What are they storing?
How large is your (I assume home-manager) closure? If this is 2-3 generations worth, that sounds about right.
That's extremely large. Like, 2x of what you'd expect a typical system to have.
You should have a look at what's using all that space using your system package manager.
If you're on btrfs and have a non-trivial subvolume setup, you can't just let
ncdu
loose on the root subvolume. You need to take a more principled approach.For assessing your actual working size, you need to ignore snapshots for instance as those are mostly the same extents as your "working set".
You need to keep in mind that snapshots do themselves take up space too though, depending on how much you've deleted or written since taking the snapshot.
btdu
is a great tool to analyse space usage of a non-trivial btrfs setup in a probabilistic fashion. It's not available in many distros but you have Nix and we have it of course ;)Snapshots are the #1 most likely cause for your space usage woes. Any space usage that you cannot explain using your working set is probably caused by them.
Also: Are you using transparent compression? IME it can reduce space usage of data that is similar to typical Nix store contents by about half.