In ~/.profile I have expanded the past thumbnail tmpfs to the entire ~/.cache, still on watch. The directory declared for use should be empty. So add the profile info, delete ~/.cache, reboot. To be sure you could do so with root in a tty while the user isn't logged in, systemd-mount will create the mount point if it doesn't exist.
Note, sizes are negotiable. They can add up to more than you have and no they don't use memory if not used. Dumping the cache on reboot can effect 'continuity'. Programs do benefit from the last session cache, it's really a incoming data consideration - do you want to wait, or pay to reload previously cached data. It's your call. Some may not like looking at generic favicons until updated. Some things that cache maps or /grits or audio/video temps and the like may be able to redirect their cache. For the most part, if something in cache is critical to the next boots operation we should consider it a bug and file on the offending package.
If we notice the example has a vda1 and not a sda1, we get into my main purpose of avoiding qcow2 size creep. Since copy-on-write can grow when overwriting the same info again and again, and deleted or unused data gives a new dimension to 'cruft'. This also is a 'backing' file where a second layer is used in numerous instances. Without the continuous cache cruft growing the 2nd layer qcow2, the file stays tidy - MB's instead of GB's. It's small enough for a temp vm to fit into a tmpfs on the host, say ~/Public/ram where the backing layer, and persistent 2nd layers are on a disk mounted in ~/Public/.images, both linked into the default /var/lib/libvirt/images for simplicity, and yet another discussion.
In other post I have mentioned the same ~/.profile method for additional devices, perhaps at ~/Music or ~/Videos. I have mentioned my TV DVR uses ~/Videos/vram as an absurdly large tmpfs. Also, I have an update not written out for the usb mounting...to be seen here eventually
https://forums.debian.net/viewtopic.php?t=155840
User permission needs set up for systemd-mount,
for my preferred polkit methods on a personal machine, see here
https://forums.debian.net/viewtopic.php ... it#p795066
I should track these older post better!
I use ~/.profile systemd-mount for most mounts of any kind. Once executed in profile they are active until shutdown. Any logoff/logon cycle ignores absent devices and existing declarations. All prior contents persist. Any 'ssh -X user@' will also safely run the sequence in that user profile.
Enjoy
Code:
#create tmpfs disk saverssystemd-mount -t tmpfs -o size=4G dram ~/Downloadssystemd-mount -t tmpfs -o size=2G ramdesk ~/Desktop systemd-mount -t tmpfs -o size=2G ramcache ~/.cacheCode:
$ dfFilesystem 1K-blocks Used Available Use% Mounted onudev 1920964 0 1920964 0% /devtmpfs 388016 628 387388 1% /run/dev/vda1 7894752 2653004 4815764 36% /tmpfs 1940068 0 1940068 0% /dev/shmtmpfs 5120 8 5112 1% /run/locktmpfs 376132 36 376096 1% /run/user/1001ramdesk 1048576 0 1048576 0% /home/user/Desktopramcache 1048576 226852 821724 22% /home/user/.cacheNote, sizes are negotiable. They can add up to more than you have and no they don't use memory if not used. Dumping the cache on reboot can effect 'continuity'. Programs do benefit from the last session cache, it's really a incoming data consideration - do you want to wait, or pay to reload previously cached data. It's your call. Some may not like looking at generic favicons until updated. Some things that cache maps or /grits or audio/video temps and the like may be able to redirect their cache. For the most part, if something in cache is critical to the next boots operation we should consider it a bug and file on the offending package.
If we notice the example has a vda1 and not a sda1, we get into my main purpose of avoiding qcow2 size creep. Since copy-on-write can grow when overwriting the same info again and again, and deleted or unused data gives a new dimension to 'cruft'. This also is a 'backing' file where a second layer is used in numerous instances. Without the continuous cache cruft growing the 2nd layer qcow2, the file stays tidy - MB's instead of GB's. It's small enough for a temp vm to fit into a tmpfs on the host, say ~/Public/ram where the backing layer, and persistent 2nd layers are on a disk mounted in ~/Public/.images, both linked into the default /var/lib/libvirt/images for simplicity, and yet another discussion.
In other post I have mentioned the same ~/.profile method for additional devices, perhaps at ~/Music or ~/Videos. I have mentioned my TV DVR uses ~/Videos/vram as an absurdly large tmpfs. Also, I have an update not written out for the usb mounting...to be seen here eventually
https://forums.debian.net/viewtopic.php?t=155840
User permission needs set up for systemd-mount,
for my preferred polkit methods on a personal machine, see here
https://forums.debian.net/viewtopic.php ... it#p795066
I should track these older post better!
I use ~/.profile systemd-mount for most mounts of any kind. Once executed in profile they are active until shutdown. Any logoff/logon cycle ignores absent devices and existing declarations. All prior contents persist. Any 'ssh -X user@' will also safely run the sequence in that user profile.
Enjoy
Statistics: Posted by CwF — 2024-09-05 17:41 — Replies 0 — Views 32