dtgreene: Drawbacks:
* The filesystem won't persist over reboots with a tmpfs, and re-downloading them every update will slow things down..
* If the portage tree doesn't fit into RAM, there could be an issue.
I wasn't implying the tmpfs was the final solution, only for extracting/preparing it so your main drive doesn't run out of inodes.
But if it's a lot of small or redundant files, making a very large zram partition could handle it as the contents are always compressed (
and blocks of zero are not stored at all). But again if you don't have enough ram even this becomes an issue.
Though i'm not familiar with the portage tree you're talking about;.
dtgreene: One possibility, though it has the drawback of being more complex, would be something like this:
* Store the portage tree in a squashfs filesystem. This is a single file on the local disk, so it only uses 1 inode there, and also takes significantly less space. (squashfs, I believe, even compresses things like inodes.)
* When it comes time to update the tree, mount the tree, then mount a tmpfs overlay over it. Now it's possible to write to the tree, though the changes don't persist.
* At some point after the update, a cron job (or similar) could re-compress the new tree. Save this to a separate squashfs image, then rename the file to atomically overwrite the old squashfs image. This could, for example, be done at shutdown, if the system is regularly powered off. )In case of a power outage, one could just re-update from the internet.)
Now we're talking a lot closer to Slax and overlapping filesystems territory. I have a particular love for Squashfs. One curious thing on Slax is the layout of the overlays, one directory of 'changes' refers to anything not mounted to a drive (
and presumably floating in ram), so you could have sorta an incremental. Saving the changes as a secondary file to overlay would speed up and prevent tons of redundant work until it reaches an acceptable size, then merging that with the original data would likely work quite well.