Where else can tmpfs be mounted besides /tmp?

[cracauer@]

No,no,no, .config has configuration after reboots.

% du -s ~/.cache/* | sort -n
[...]
133840  /home/cracauer/.cache/RawTherapee
291204  /home/cracauer/.cache/calibre
322308  /home/cracauer/.cache/pip
353200  /home/cracauer/.cache/wine
1327628 /home/cracauer/.cache/mozilla
3401344 /home/cracauer/.cache/common-lisp

 

[Alain De Vos]

what do you think of,

/usr/bin/truncate   -s 0 /var/crash/*
# /usr/bin/truncate -s 0 /var/log/*
rm -vfR                  /usr/ports/distfiles/*
rm -vfR                  /var/cache/pkg/*

 

[ralphbsz]

Another question nobody asked: Does it actually help performance? Did anyone measure before suggesting it?

My educated guess: A file system with atime turned off and the async option will be just as fast; the occasional disk write is asynchronous, and it can use less memory if there is pressure.

 

[Alain De Vos]

once mounted was it ext2/ext3/ext4 , with async off & atime off, way , way ,way much faster.

 

[mer]

Another question nobody asked: Does it actually help performance? Did anyone measure before suggesting it?

My educated guess: A file system with atime turned off and the async option will be just as fast; the occasional disk write is asynchronous, and it can use less memory if there is pressure.

Thank you. This meshes nicely with my question about "what problem is being solved by having $HOME/.cache tmpfs", which I don't think has been answered yet.

 

[Beastie]

And python stores in "~/.local/lib".

And in ~/.cache/pip.

 

[Alain De Vos]

Yes. You can safely delete the contents of ~/.cache/pip at any time.
This was AI....
No, Python itself does not install into ~/.cache/pip. That directory is used specifically by pip (Python's package manager) as a storage unit to speed up future installations.

 

[Beastie]

That directory is used specifically by pip (Python's package manager) as a storage unit to speed up future installations.

Exactly. And some packages can be really big. Personally I prefer to keep them permanently.

 

[Beastie]

then what problem is actually being solved by having $HOME/.cache mounted tmpfs?

As I said, I don't do that. Only for some specific subdirectories, not the entire .cache directory.

The only thing I can see is cached data for applications like web browsers, but again, if it's only cleared when you reboot, who cares? You can get the same result by adding "rm -rf $HOME/.cache" in your .login/.profile to delete it on your login.

Because the files are not created on the disk to start with. The advantage of keeping all of the browser's cache and history is, for me at least, marginal at best.
With some websites — LLM-powered search engines among others, I've noticed — I see constant disk activity. With a memory-based profile, no more disk churning.
Right now, with an uptime of less than 3 hours, my browser's profile is worth more than 370MB and 11,000 files. That's only after checking these forums and a few YouTube channels. All of that would be on my user profile, growing and growing every day. No thanks.

 

[mer]

As I said, I don't do that. Only for some specific subdirectories, not the entire .cache directory.


Because the files are not created on the disk to start with. The advantage of keeping all of the browser's cache and history is, for me at least, marginal at best.
With some websites — LLM-powered search engines among others, I've noticed — I see constant disk activity. With a memory-based profile, no more disk churning.
Right now, with an uptime of less than 3 hours, my browser's profile is worth more than 370MB and 11,000 files. That's only after checking these forums and a few YouTube channels. All of that would be on my user profile, growing and growing every day. No thanks.

Ok, but if tmpfs is only cleared on reboot, all that growing is currently happening in memory, memory that is only reclaimed on reboot. What is more important, memory or storage space?
If you really don't care about $HOME/.cache, put a line rm -rf $HOME/.cache in your .xinitrc.

So maybe no more disk churning, but at the cost of less available memory. It's one thing if we are talking about "10s of MB" but completely different if we are talking "10s of GB".

Memory vs physical storage. Me, for most cases, I'll take more available memory