[SOLVED] Move Vivaldi-Snapshot Cache to /tmp, OR move /home/username/.cache/ to /tmp ?



  • [color=#8800ff]Hi. I feel silly for asking this, especially since ~15 months ago i did manage to do it [later i chose to undo it] but now cannot recall [i]how[/i] i did it. Extensive recent DDG'ing gave me lots of hits, many useless, some teasingly close but not quite my exact objective. My system is Linux Mint x64 17.3 KDE 4.14.2, 32 GB RAM, ~240 GB SSD [partitions [i]/, /opt, /home[/i] (encrypted)]. 2 TB HDD [[i]Swap[/i], & all my data]. I have [i]/tmp[/i] mounted per fstab as ram-drive [i]tmpfs[/i]. Currently my Mint cache sits per default in [i]/home[/i], ie... [i]/home/steffie/.cache/[/i] . Also, said .[i]cache[/i] directory holds >18,000 files & ~2.3 GB, comprising:[/color] [attachment=3959]cache_20160627_20:33:06.png[/attachment] [color=#8800ff]At bare minimum i'm interested in [1] moving my Vivaldi-Snapshot cache folder from[i] /home/steffie/.cache[/i] to [i]/tmp[/i] , but [2] as potential alternative [as this might yield me benefits beyond only V] move the whole Mint cache entirely to [i]/tmp[/i]. [1] I moved my Vivaldi-Snapshot cache folder from [i]/home/steffie/.cache[/i] to [i]/tmp[/i] , then i symlinked its new location back to its original location. My assumption was that when V launched, it would initially go to the original cache folder as usual, then jump to the new location via the symlink. In contradiction, V [u]entirely fails to launch[/u]... not a single process for it appears in KDE System Monitor. Only after i undo these changes will V launch again. Hmmm. [2] Here's two pertinent lines from my amended fstab: [i]tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0 tmpfs /tmp/.cache tmpfs defaults,noatime,mode=1777 0 0[/i] Consequently: [/color][attachment=3960]df_001_20160627_20:52:02.png[/attachment] [color=#8800ff]I then moved the current Mint .[i]cache[/i] directory from [i]/home[/i] to [i]/tmp[/i] ... BUT ... Mint responded by immediately creating a new .[i]cache[/i] directory in the original location. This naturally prevented me symlinking my moved .[i]cache[/i] back to [i]/home[/i]. Furthermore, when i launch V, or other pgms, NO entries at all appear in [i]/tmp/.cache[/i] , implying IMO that this new cache location is inactive (??). As i said earlier, 15 months ago i somehow surmounted the [2] problem, but can't remember how i avoided the present difficulty. Any help would be really appreciated pls. PS -- oh, fyi btw, on my HDD i run multiple VMs [Win & many different Linux distros]. One of those VMs is a near-duplicate of my real Mint KDE OS, & if i can solve #1 &/or #2 i intend to trial first in this Mint VM, after which (if no unintended adverse consequences occur] i'd deploy one or the other in my real Mint OS. I hope i'm wrong but have a sneaking suspicion re #2 that i might need to do the manipulations via a LiveUSB with my real Mint not running. If so, i think i know how to do that for "real", but am not sure i can do that for the VM (??) [/color] Attachments: [img]https://forum.vivaldi.net/uploads/attachments/26803/cache_20160627_20:33:06.png[/img],[img]https://forum.vivaldi.net/uploads/attachments/26803/df_001_20160627_20:52:02.png[/img]



  • You should mount directly /home/steffie/.cache or the vivaldi cache directory (e.g. /home/steffie/.cache/vivaldi-snapshot) as tmpfs, instead of using symlinks.

    You can mount directories inside other directories without problem (if you are coming from Windows, you might not be used to this ^^)

    You should be able to mount the vivaldi cache directory on your live machine (VM, whatever) but you should close vivaldi beforehand. If you would rather do that for the whole ~/.cache it might be a bit trickier (if you have applications running, that use that directory).



  • Hi & thanks crazygolem

    Oh wow i can be so dense sometimes! Why did i not realise already what you said? Sigh. In my Mint VM i have now edited fstab thus:
    #tmpfs /tmp/.cache tmpfs defaults,noatime,mode=1777 0 0
    tmpfs /home/steffie/.cache/vivaldi-snapshot tmpfs defaults,noatime,mode=1777 0 0

    …& df -h now shows:

    tmpfs 2.0G 16K 2.0G 1% /tmp
    tmpfs 2.0G 0 2.0G 0% /home/steffie/.cache/vivaldi-snapshot

    In this edited VM my V-SS launches fine, & so far everything seems to still work ok (i had been slightly anxious about possible bad V behaviour resulting from V's cache being cleared each reboot [per normal [i]tmpfs behaviour of course], but so far it seems happy. I'll test more in the VM tomorrow & if it stays happy i'll then deploy this fstab edit in my real Mint KDE OS.

    Thanks again.



  • Hello,
    This is mostly over my head. :huh: How is it different from
    vivaldi-snapshot –disk-cache-dir=/tmp/vivaldi-cache,
    which works for me? Anything I should know? :unsure: Thanks!



  • Rats, sigh. "tmpfs /home/steffie/.cache/vivaldi-snapshot" worked nicely in my VM. Later, "tmpfs /home/steffie/.cache" also worked nicely in my VM.

    Encouraged, i replicated the former in my real Mint's fstab, rebooted, & … found nothing had changed. I deactivated that fstab line & tried the latter one, rebooted, &… still nothing had changed. Running df -h confirmed these facts.

    Huh? Works perfectly in my VM, but won't work at all in my real Mint? Golly. The only possible cause i can think of is that my VM does not have an encrypted /home partition, whereas my real Mint's /home is encrypted [with .[i]ecryptfs, applied during original installation, way back]. Hence, maybe ecryptfs blocks tmpfs? A couple of hours of DDG did not answer this question, nor suggest a workaround.

    Does anyone have suggestions pls?



  • Hi again wognath. Ta, but… isn't that a Windows command / switch? I use Linux.



  • Hi, main difference of tmpfs vs. –disk-cache-dir= is tmpfs is in RAM and other is on hard disk.
    You loose all tmpfs cache after restart but it is 100 times faster.

    Cheers, mib



  • @Steffie:

    Hence, maybe ecryptfs blocks tmpfs?

    It should not. However if the encrypted file system is not yet mounted when your system tries to mount the cache directory, it won't be able to. Try to figure out when and in what order they are mounted. dmesg might be of some help.

    @mib2berlin:

    Hi, main difference of tmpfs vs. –disk-cache-dir= is tmpfs is in RAM and other is on hard disk.

    You can make –disk-cache-dir point to a directory that is mounted on tmpfs, so actually that's not the difference. The real difference is that the strategy of mounting the default cache directory on tmpfs also works for applications that do not allow to change the default cache directory.



  • Thanks mib2berlin and crazygolem for your informative replies. Steffie, I use Linux also, Fatdog. Before I left Opera, I asked for a list of valid command-line switches but never got it, so I do trial and error with this huge :blink: list: http://peter.sh/experiments/chromium-command-line-switches/ Some appear to be OS-specific, others not.



  • Hi wognath. Gaaaaahhh, yes indeed you do, sorry for my crap memory & thus unintentional insult implicit in my reply. I'm such a dope. :oops:



  • Hi mib2berlin, yes, my preference for using tmpfs is indeed that it's using RAM, hence benefits of comparatively great speed, + auto-purging at reboot. Conversely, the trouble with the latter point is that i mainly Sleep my tower at night not SD it, hence the RAM purge accordingly occurs rarely. I wanna manage that via cron, but to date have had limited success – i have dabbled with tmpreaper to purge my /tmp in tmpfs every few days, but eventually had to abandon it coz the bugger kept also obliterating the critical _xauth-1000-0 file, without which Mint KDE will no longer give me any Admin privilege for eg, when i need to edit a root file, install / update SW via Synaptic / Update Manager, etc. I just love Linux, & plan never to return to Windows, but i'm still such a babe in the woods with it; Linux Dark Arts still hold considerable mystery for me [but on t'other hand, that keeps it interesting].



  • @crazygolem:

    ["Steffie"]Hence, maybe ecryptfs blocks tmpfs?
    It should not. However if the encrypted file system is not yet mounted when your system tries to mount the cache directory, it won't be able to. Try to figure out when and in what order they are mounted. dmesg might be of some help.

    Hi again crazygolem – thanks!
    Re "blue", maybe i'm simply interpreting this all wrong, but doesn't the sequence listed in fstab = the sequence in which the kernel proceeds with the mountings? With all extraneous stuff removed, here's the relevant fstab lines:

    UUID=<<snip>> / ext4 noatime,nodiratime,errors=remount-ro 0 1
    UUID=<<snip>> /home ext4 noatime,nodiratime,defaults 0 2
    UUID=<<snip>> /opt ext4 noatime,nodiratime,defaults 0 2
    /dev/mapper/cryptswap1 none swap sw, noauto 0 0
    tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
    tmpfs /home/steffie/.cache tmpfs defaults,noatime,mode=1777 0 0

    Re the "brown bold", thanks… i tried it in konsole, & was overwhelmed with the stream of [to me] incomprehensible text that resulted. Is there any value in posting any of it here pls?</snip></snip></snip>



  • Ha, looks like the Curse Of Steffie has arisen once again. Q: How to abruptly end a conversation? A: Have Steffie join it.



  • @Steffie:

    Rats, sigh. "tmpfs /home/steffie/.cache/vivaldi-snapshot" worked nicely in my VM. Later, "tmpfs /home/steffie/.cache" also worked nicely in my VM.

    Encouraged, i replicated the former in my real Mint's fstab, rebooted, & … found nothing had changed. I deactivated that fstab line & tried the latter one, rebooted, &… still nothing had changed. Running df -h confirmed these facts.

    Huh? Works perfectly in my VM, but won't work at all in my real Mint? Golly. The only possible cause i can think of is that my VM does not have an encrypted /home partition, whereas my real Mint's /home is encrypted [with .[i]ecryptfs, applied during original installation, way back]. Hence, maybe ecryptfs blocks tmpfs? A couple of hours of DDG did not answer this question, nor suggest a workaround.

    Does anyone have suggestions pls?

    ddg "encryptfs + tmpfs" among other gave this result: http://forums.debian.net/viewtopic.php?t=61195



  • CONSOLIDATION POST. The following text all comes from these two posts in a different thread, & i've now reproduced them herein, before continuing the discussion in this my original thread.

    1. https://vivaldi.net/en-US/forum/security-and-privacy/13114-show-passwords-how#68410
    2. https://vivaldi.net/en-US/forum/security-and-privacy/13114-show-passwords-how#68561

    Show passwords - how? 18 Jul 2016 23:51 #68410
    jsfarinet
    New Member

    In a less sophisticated way, apparently, i had the same idea:

    in /etc/fstab i have:
    tmpfs /tmp tmpfs nodev,nosuid,size=30%,mode=1777 0 0

    Then, i changed the /usr/share/applications/vivaldi-snapshot.desktop to start vivaldi this way:
    Exec=/usr/bin/vivaldi-snapshot –disk-cache-dir=/tmp %U

    Now the cache files seems to be directed to /tmp - which is temporary and with any reboot will be flushed. It's not ideal, but it's a way which btw, speeds ip significantly vivaldi.

    PS. I'd have liked to have tmp in zram, but i was unable to configure that in devuan+openrc: The nice script of Martin Vaeth for (gentoo) openrc was not adaptable to debian/devuan (i suspect because of a poor implementation of openrc). So i used tmpfs.

    Show passwords - how? Today 11:03 #68561
    Steffie
    Platinum Member

    Oh jsfarinet, i'm really sorry! I hate it when people do this to me, so i'm embarrassed to have done it to you [ie, not replied, which looks very rude & inconsiderate of me]. I did indeed read your reply there t'other day [thank you!!] & i will certainly reply there as soon as i can, but (a) i needed time to mull over the info in that link which i found confusing [& a bit scary re breaking stuff] & i'm still unsure of its applicability to me, (b) i've been distracted by other [unrelated] issues. Blush.

    PS - For the sake of continuity, consistency, & anal-retentives all over the world of whom i'm clearly an example, I'm going to copy my reply from this current thread, & your vivaldi.net/en-US/forum/security-and-pri…-passwords-how#68410 also from this thread, into my original thread vivaldi.net/en-US/forum/vivaldi-browser-...e-cache-to-tmp#66286, & then carry on all further discussion there. –> ie, here.



  • Hi jsfarinet

    When i did my original DDG research, that link you posted for me was actually one that i also found, but i had dismissed it back then as i thought it wasn't applicable to me, + the OP seemed to break things … a path down which i was reluctant to walk. Having re-read it following your reply, i realised that originally i had not noticed the final part:

    "I decided to go with a nice simple scriptable tmpfs:
    echo "tmpfs /tmp tmpfs defaults,noexec,nosuid 0 0" | sudo tee -a /etc/fstab
    "

    That might be helpful for me, though i do not yet properly understand it… it sounds less like a simple fstab edit [with which i am comfortable] but more like maybe an executable script i'd need to write & somehow run [this is an area in which i'm very non-confident of myself]. Hence for now i've placed this on the back-burner, whilst i consider the following alternative.

    wognath's 30 June "vivaldi-snapshot –disk-cache-dir=/tmp/vivaldi-cache" & your "Exec=/usr/bin/vivaldi-snapshot –disk-cache-dir=/tmp %U" gave me a new idea.

    Yours first: i didn't know of the existence of /usr/bin/vivaldi-snapshot , so this was already interesting to me. I have not [yet?] tried editing it, as i fear that every time V SS updates i would have to repeat this step, which seems undesirably inefficient to a lazy cow like me. Rather, yours + wognath's together made me think i should simply try editing my Cairo-Dock Launcher for Vivaldi, to add that Command Line Switch. Given that in my real Mint OS [ie, not just the VM], my existing fstab is already correctly running my /tmp in RAM via tmpfs, i'm hoping that "your" CLS might provide the missing puzzle piece. As soon as i post this reply, i'll close V, edit the Launcher, & see what new carnage i've unwittingly created.

    …....................................................................................
    My on-SSD OS = Linux Mint x64 17.3 KDE 4.14.2.



  • Well, great big buckets of yaaaaaaaaaaaaaaaaaaaaaaay.

    Thanks so very much to everyone who replied & helped me here; i'm most grateful.

    Summary.
    1. Before editing my Cairo-Dock Launcher for Vivaldi, to add that Command Line Switch, i saw that my /home/steffie/.cache/ contained all these [highlighted] chromium-engined browser cache directories:

    [attachment=4098]chromium-enginedbrowsercachedirectories_20160720_12:55:30.png[/attachment]

    2. I assumed / hoped they were only legacy [at least, V's one specifically, once i made my CLS edit], so i removed the V-SS one.

    3. Also before my edit, i saw that /home/steffie/.config/vivaldi-snapshot/Default/ contained Application Cache folder, one of whose subfolders was Cache. Making the same assumption, i removed the parent folder, ie, Application Cache .

    4. I edited my Cairo-Dock Launcher V-SS command from firejail vivaldi-snapshot to firejail vivaldi-snapshot –disk-cache-dir=/tmp/ %U [thanks jsfarinet!!!] then used it to launch V.

    5. I observed that there was no resurrection / recreation of the deleted folders of #2 & #3 [good]. I also observed that /tmp/ now contained a new folder;

    [attachment=4099]VtmpCache_20160720_12:47:14.png[/attachment]

    6. Within V, in vivaldi://about/ , under Command Line, i saw this NEW entry _:

    /usr/bin/vivaldi-snapshot –user-data-dir=/home/steffie/.config/vivaldi-snapshot --ppapi-flash-path=/opt/google/chrome/PepperFlash/libpepflashplayer.so --ppapi-flash-version=22.0.0.192 –disk-cache-dir=/tmp –always-authorize-plugins --disable-translate --window-depth=24 --x11-visual-id=33 --wm-user-time-ms=11833550 --flag-switches-begin --enable-account-consistency --disable-offer-upload-credit-cards --enable-devtools-experiments --disable-fill-on-account-select --enable-grouped-history --disable-offer-store-unmasked-wallet-cards --disable-offline-auto-reload-visible-only --enable-offline-auto-reload --disable-password-generation --disable-push-api-background-mode --enable-single-click-autofill --enable-tab-audio-muting --mark-non-secure-as=non-secure --save-page-as-mhtml --enable-smooth-scrolling --touch-events=disabled --wallet-service-use-sandbox=0 --enable-features=DownloadResumption,enable-manual-password-generation,enable-password-force-saving --disable-features=ScrollAnchoring,enable-automatic-password-saving --flag-switches-end %U

    7. Testing V in this mode, AFAIK, everything still seemed to behave properly [phew].

    8. Though naturally df -h still does not now indicate that V's cache is running in RAM, i suppose i simply have to deductively trust that it is: my /tmp certainly IS running in RAM, & V's cache now seems to be running in /tmp, so deductively [presumably hopefully touch wood fingers crossed] ipso facto my objective is now achieved.

    9. I rebooted pc, then confirmed that /tmp no longer contained Cache, exactly as expected/hoped. After relaunching V, it then correctly reappeared anew.

    10. Upon reflection i realised a further tweak was needed. Though V-SS is my default browser, in heavy use all day & late into nights [no life], i do occasionally run other browsers, including chromium-based browsers, as per pic @ #1 [EXCEPT Chrome, which is usually NOT installed, but currently is temporarily whilst i fight a new V Netflix problem, per a separate post of mine]. I'd like to replicate this temp cache trick for each of them too, but i realised that a real mess might result if ever i run more than one of them simultaneously, coz they'd all "claim" the same /tmp/Cache folder. Ouch. Then i finally understood the beauty of wognath's CLS [thank you!!!]… it would create separate dedicated folders. Thus now, with my Cairo-Dock Launcher for Vivaldi edited to firejail vivaldi-snapshot –disk-cache-dir=/tmp/vivaldi-cache %U & similarly mimicked [with suitable name changes] for the other browsers, i now see [having also deleted all the now-legacy cache folders in [i]/home/steffie/.cache/]:

    [attachment=4100]chromium-enginedbrowsercachedirectoriesintmp_20160720_14:53:24.png[/attachment]

    Yaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaay [thanks again].

    …....................................................................................
    My on-SSD OS = Linux Mint x64 17.3 KDE 4.14.2.

    Attachments:
    ,,_



  • but doesn't the sequence listed in fstab = the sequence in which the kernel proceeds with the mountings?

    Basically, the order of your mount points is important (not always).

    fstab's man page reads:

    The order of records in fstab is important because fsck, mount, and umount sequentially iterate through fstab doing their thing.

    However mount has an -F flag, which

    […] will make mount fork, so that the filesystems are mounted simultaneously.

    (from mount's man page), and it is apparently the default on some systems with some configurations (probably Ubuntu?)

    The thing is, you cannot mount something in a directory that does not exist, so if you have nested mounts you need to be careful about the order of your mounts. From mount's man (-F flag again):

    A disadvantage is that the mounts are done in undefined order. Thus, you cannot use this option if you want to mount both /usr and /usr/spool.

    Since you use an encrypted user directory, I suppose that it is mounted when you log into your user account? (I am not familiar with this kind of setups)
    If so, then your fstab has already been parsed at that point during the boot process, and whatever mount was not able to mount (in your case /home/steffie/.cache, because although /home was mounted, /home/steffie was not) will not be mounted automagically later. You need to take car of that yourself, either by hand or using a script sourced by your system when you log in (or maybe by configuring systemd somehow?)

    Check out that post on stackexchange for a probably better explanation. The poster recommends to not used nested mount points in your case, but I'm pretty sure it should be doable cleanly somehow (but not using fstab alone, obviously; you might want to check the noauto option).

    The command dmesg outputs low-level (kernel) logs, and you can see in there the order of your mounts and mount failures (you'd probably want to pipe its output into less).

    TL;DR: It worked in your VM because you did not use an encrypted user directory, and since you use one for your main setup, it does not work anymore.



  • Many thanks for getting back to me, crazygolem. Oh gollygosh, having read your interesting info, i think i know when i'm beaten, when to just wave the white flag… & that's pretty much...now. As i'd said to you privately, though in principle i'd have preferred to have achieved my objective the fstab way rather than the CLS way [a preference which probably illustrates my nuttiness anyway], it would appear that if there's any chance of doing so now, it'll likely involve a complexity-level requiring a greater neuron-set than i possess. I do appreciate your help to this point, all the same.



  • I did a bit more research, and it should totally be doable using systemd mounts. Check out systemd.mount, systemd.automount, and specifically how they allow to specify dependencies using Before= and After=.

    Of particular interest, there is the following bit on archlinux' wiki:

    If you have encrypted filesystems with keyfiles, you can also add the noauto parameter to the corresponding entries in /etc/crypttab. systemd will then not open the encrypted device on boot, but instead wait until it is actually accessed and then automatically open it with the specified keyfile before mounting it.


Log in to reply
 

Looks like your connection to Vivaldi Forum was lost, please wait while we try to reconnect.