Noticed that free disk space on Kubuntu partition was dwindling quickly. It turned out, that folder was over 2GB in size. I was wondering if this was due to recent upgrade to 4.7.4? Does anybody observes something similar?
Announcement
Collapse
No announcement yet.
Anybody has a giant /var/tmp/kdecache-(user name)?
Collapse
This topic is closed.
X
X
-
KDE Forum / kdecache is huge, for God's sake! : http://forum.kde.org/viewtopic.php?f=22&t=96677
Bug 190209 - /var/tmp/kdecache-USER/kpc grows to enormous size (+150MB for each plasma theme tried) : http://bugs.kde.org/show_bug.cgi?id=190209
Bug 283921 - Switching/customising desktop themes causes massive cache expansion : https://bugs.kde.org/show_bug.cgi?id=283921
It is a cache - you could clean it.
KDE Forum / What are the consequences if I delete KDE cache files: http://forum.kde.org/viewtopic.php?f=66&t=89866
KDE Forum / Accumulating data in kdecache/kpc folders. Erasable?: http://forum.kde.org/viewtopic.php?f=17&t=45909Last edited by OneLine; Feb 07, 2012, 05:19 PM.
- Top
- Bottom
-
Pan-Galactic QuordlepleenSo Long, and Thanks for All the Fish
- Jul 2011
- 9524
- Seattle, WA, USA
- Send PM
Is there any reason for stuff in /var/tmp to persist reboots? I haven't come across one. So I've configured both temporary directories to run in RAM disks. Reduces unnecessary wear on SSDs, perks up system performance a bit, and cuts down on bloat accumulation.
My /etc/fstab:
Code:# /etc/fstab: static file system information. # # Use 'blkid -o value -s UUID' to print the universally unique identifier # for a device; this may be used with UUID= as a more robust way to name # devices that works even if disks are added and removed. See fstab(5). # # <file system> <mount point> <type> <options> <dump> <pass> proc /proc proc nodev,noexec,nosuid 0 0 # / was on /dev/sda1 during installation UUID=3175f1e1-f320-496d-b32e-7c43d466c7f1 / ext4 noatime,discard,data=writeback 0 1 # swap was on /dev/sda2 during installation UUID=25a3c459-8fb3-4c3a-89ae-55f6bbe13934 none swap sw 0 0 # tmpfs /tmp tmpfs noatime,mode=1777 0 0 tmpfs /var/tmp tmpfs noatime,mode=1777 0 0
1. sudo rm -rfv /tmp/*
2. sudo rm -rfv /var/tmp/*
3. Edit your /etc/fstab and add the two lines you see in the bottom of the one I posted above
4. sudo mount -a
- Top
- Bottom
Comment
-
-
Pan-Galactic QuordlepleenSo Long, and Thanks for All the Fish
- Jul 2011
- 9524
- Seattle, WA, USA
- Send PM
-
AFAIK RHEL distros clean /var/tmp every 30 days by default. I suspect the contents of /var/tmp might make bootup or desktop loading a bit faster, but won't prevent booting.
As I only boot when there's a new kernel or driver I need, I doubt it makes much difference to me. My typical uptime runs into weeks/months not minutes/hours like you laptop users... lol
- Top
- Bottom
Comment
-
-
+1 on keeping all the temporary files in RAM. Let the system speed your stuff up, that's why you paid for the RAM. A basic example:
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
tmpfs /var/log tmpfs defaults,noatime,mode=0755 0 0
tmpfs /var/tmp tmpfs defaults,noatime,mode=1777 0 0
Though /var/spool, /var/mail and stuff can go there as well. Gecko browsers can keep their cache in RAM too - about:config, create a string value for browser.cache.disk.parent_directory with /dev/shm/browsercacheLast edited by Guest; Feb 08, 2012, 07:18 AM.
- Top
- Bottom
Comment
-
Originally posted by oshunlulvr View PostAFAIK RHEL distros clean /var/tmp every 30 days by default. I suspect the contents of /var/tmp might make bootup or desktop loading a bit faster, but won't prevent booting.
As I only boot when there's a new kernel or driver I need, I doubt it makes much difference to me. My typical uptime runs into weeks/months not minutes/hours like you laptop users... lol
- Top
- Bottom
Comment
-
Pan-Galactic QuordlepleenSo Long, and Thanks for All the Fish
- Jul 2011
- 9524
- Seattle, WA, USA
- Send PM
Originally posted by lo_koraco View Posttmpfs /var/log tmpfs defaults,noatime,mode=0755 0 0
- Top
- Bottom
Comment
Comment