tmpfs for ~/.cache?
-
You definitely do not want to set up the
~/.cache/directory as a tmpfs mount. You are only asking for problems if you do that, especially if you use dekko or libertine. -
hi dobey,
can you be a bit more specific about these possible problems arising?
with tmpfs, you would start with a clean cache everytime the phone gets initially booted - but this does not mean it can't be repopulated anymore.
-
@utouchuser
With dekko and libertine there is more than just 'cache' information in the .cache directory.
So erasing it at each reboot will destroy your email configuration... -
ok, thanks for pointing out.
i was not aware of this situation, i believed that sensible data is stored elswhere (~/.config?) in order to prevent a scenario like this.
under linux, this is actually my setup for years without problems so far.
-
@AppLee Exactly! And precisely, concerning dekko2 at the moment, it can be useful to keep a backup of the dekko2.dekkoproject directories in .cache, .config, .local/share so that we can restore them if necessary... It was useful to me
-
@utouchuser Well, tmpfs is just a RAM disk. So anything you put in a tmpfs mount, will take up space in RAM. You will be rebooting quite often if you make
~/.cache/a tmpfs mount, and actually use the phone at all, especially if you want to download anything, for example. -
@dobey said in tmpfs for ~/.cache?:
Well, tmpfs is just a RAM disk. So anything you put in a tmpfs mount, will take up space in RAM
true, but it should also be mentioned that space is allocated dynamically, no data = zero disk space. the whole idea behind a tmpfs for /.cache is a further bit of privacy (perhaps security too?), starting off with a clean cache on every reboot.
another benefit could be an increase of speed, ram is faster than any traditional data carrier. after all, this is about mobile phones and not classic desktop enviroments, so it also depends on the device ut is running on, no doubt.
-
@utouchuser said in tmpfs for ~/.cache?:
true, but it should also be mentioned that space is allocated dynamically, no data = zero disk space. the whole idea behind a tmpfs for /.cache is a further bit of privacy (perhaps security too?), starting off with a clean cache on every reboot.
There will never be no data, as Qt writes cache for QML compilation and other things to it. I also don't think it will really increase privacy or security. Confined apps already can't read data from other apps, only their own cache, so this won't change anything in that respect. It sounds like a workaround for other problems in that case.
@utouchuser said in tmpfs for ~/.cache?:
another benefit could be an increase of speed, ram is faster than any traditional data carrier. after all, this is about mobile phones and not classic desktop enviroments, so it also depends on the device ut is running on, no doubt.
Rather you will actually end up with the opposite, as RAM will fill quickly with QML and image caches from apps, and because these caches will need to be rebuilt all the time, apps will be slower to start and use. And indeed we're talking about mobile devices, so you don't have 64G of RAM, but more often 1-2, or a 3-4 on most newer devices. Some higher end devices might have more available, but still nowhere enough to make this a useful thing to do. Also, as mobile devices are already using solid state storage, read/write speeds aren't a huge hindrance, unless you're using a bad app which is constantly hitting disk, which shouldn't be done (every write to disk reduces the lifespan of the storage).
-
@dobey: you are much more into this matter than me and the points you mention seem valid. in the end, this was just a vague idea that came to my mind while thinking of improving privacy and performance a bit further.
i hope further weird ideas are still welcome in this forum
-
Just to add what you mentioned, there is also an issue with Mobile updates in the background gobbling up cycles and RAM, when combined with say the zoom app, running multi-party or even 2 party, these items take longer and can/will slow foreground tasks, like screen sharing where the host is displaying/reading from local storage, or worse yet sharing tight VNC view to help someone with a support issue, lots of nasty secondary and exception use cases out there, and a few primary which will quickly hamper the foreground task.
The solution is software int. controlled write to local storage , which uses per process/app queuing, concatenation of the session write blocks, then single block session write to store... to get within 95% of the actual media write speed... , this works w/ VRAM setups as well, when you are RAM constrained, the VRAM block writes by the OS get super fast,
It's what we do at cloudprox.com on Ubuntu in the DCs and Colo space at the moment (to actually get remote workplaces to work at scale with fast IOPS/Gbsec without breaking the bank) , we are looking at how to bring the same fast write functionality on to Mobile and IOT devices, as it is indeed the choke point for everything, and will easily turbocharge ubuntu touch environs by at least 5X
plus your media lasts 5X to 30X longer, and you use significantly less battery, it's the OS juggling between threads and processes which kills your battery life.
r2
