So, I’m using anything-sync-daemon (asd) and I’m just wondering if it’s working as it should.
I’m using it to manage the chromium cache directory.
It’s suppose to “move” this directory in tmpfs (i.e. in RAM) and synchronize it to the hard drive from time to time…
So when I “ask” it if everything is going according to plan, it seems to tell me “yes”:
$ asd p
Waiting for lock...
flock: getting lock took 0.000002 seconds
flock: executing /usr/bin/asd
Anything-sync-daemon v6.0.0 on EndeavourOS
Systemd service is currently active.
Systemd resync service is currently active.
Overlayfs v23 is currently active.
Asd will manage the following per /run/asd.conf settings:
owner/group id: user/1000
target to manage: /home/user/.cache/chromium
sync target: /home/user/.cache/.chromium-backup_asd
tmpfs target: /tmp/asd-user/home/user/.cache/chromium
dir size: 421M
overlayfs size: 280K
recovery dirs: 5 <- delete with the c option
dir path/size: /home/user/.cache/.chromium-backup_asd-crashrecovery-20240210_204103.tar.zstd (267M)
dir path/size: /home/user/.cache/.chromium-backup_asd-crashrecovery-20240128_121006.tar.zstd (4,0K)
dir path/size: /home/user/.cache/.chromium-backup_asd-crashrecovery-20240128_114248.tar.zstd (8,6M)
dir path/size: /home/user/.cache/.chromium-backup_asd-crashrecovery-20240116_191014.tar.zstd (298M)
dir path/size: /home/user/.cache/.chromium-backup_asd-crashrecovery-20240111_141324.tar.zstd (312M)
But if I look at the “managed” folder ( /home/user/.cache/chromium) it is still a “regular” directory, shouldn’t it rather be a symbolic link to /tmp/asd-user/home/user/.cache/chromium?
I’m using profile-sync-daemon (psd) to achieve the same behavior with my browsers’ profiles, and, in that case, the managed directories are (became) indeed symlinks to the directories in tmpfs…
Have I done something wrong or is asd working as it should ?
At some point in the past, I did try both anything-sync-daemon and profile-sync-daemon but I never used them for an extended period of time to be able to gain and share any relevant insight about them.
However, I just had a glance at the ArchWiki article on anything-sync-daemon:
anything-sync-daemon (asd) is a tiny pseudo-daemon designed to manage user specified directories referred to as sync targets from here on out, in tmpfs and to periodically sync them back to the physical disc (HDD/SSD). This is accomplished via a bind mounting step and an innovative use of rsync to maintain synchronization between a tmpfs copy and media-bound backups. Additionally, asd features several crash recovery features.
Not sure if the “bind mounting” step could explain that you are seeing the managed directory as a regular directory and not a symlink to a directory in /tmp/asd-user/… ?
Doesn’t this achieve another goal, namely to consider cache as temporary and thus deleted between reboots?
With asd the managed directory is written back to disk before reboot or shutdown.
Yes exactly, the goal here would be to have the cache directory in tmpfs and to periodically sync it back to the physical disc.
I would like to think that this is working, but the lack of symlink makes me wonder… (but hey, asd did indeed created the files in /tmp).
via a bind mounting step
So, instead of creating symlinks (like psd), it would use bind mounting… hmmm my lack of knowledge prevent me to fully understand the difference/advantages compared to symlinks, but what I really wonder is does the original directory still get written on ?? In which case that would defeat the whole purpose… so I guess not ?
You should read the Arch wiki pages on anything-sync-daemon and especially profile-sync-daemon.
Warning: If syncing browser profiles is desired, it is recommended NOT to use asd for this purpose. Instead, use Profile-sync-daemon which has built in sanity checks for unique situations specific to running a browser profile in tmpfs. Anything-sync-daemon does not have these checks; under certain circumstances, browser profile data can be lost. You have been warned.
Note:
Some browsers such as Chrome/Chromium or Firefox (since v21) actually keep their cache directories separately from their profile directory. It is not within the scope of profile-sync-daemon to modify this behavior; users are encouraged to refer to the Chromium tweaks#Cache in tmpfs section for Chromium and to the Firefox on RAM article for several workarounds.
I use profile-sync-daemon for Chrome’s profiles, and I use an fstab entry (as defined in the Chromium tweaks#Cache in tmpfs wiki page to move Chrome’s cache to RAM.
I use profile-sync-daemon for Firefox’, Chrome’ and LibreWolf’s profiles, it does work perfectly (and it does create symlinks).
I use anything-sync-daemon for Chome’s (chromium in my case) cache. I don’t keep cache for Firefox nor LibreWolf.
So anyway, yes, I do grasp the fact that the cache directories are indeed separate from the profile directories.
And, if you look at the wiki, asd is mentioned a couple of time to achieve the same behavior as psd, but for cache instead of profiles:
Note: Cache is stored separately from Firefox default profiles’ folder (/home/$USER/.mozilla/firefox/): it is found by default in /home/$USER/.cache/mozilla/firefox/. This is similar to what Chromium and other browsers do. Therefore, sections #Place profile in RAM using tools and #Place profile in RAM manually do not deal with cache relocating and syncing but only with profile adjustments. See the first note of Profile-sync-daemon for more details. Anything-sync-daemon may be used to achieve the same thing as Option 2 for cache folders.
Every object loaded (html page, jpeg image, css stylesheet, gif banner) is saved in the Firefox cache for future use without the need to download it again […] newly loaded objects are written to memory and older objects are removed.
An alternative approach is to use about:config settings:
[…]
This method has some drawbacks:
- The content of currently browsed webpages is lost if the browser crashes or after a reboot, this can be avoided using anything-sync-daemon or any similar periodically-syncing script so that cache gets copied over to the drive on a regular basis
[…]
I am just wondering if it is working as intended (command $ asd p says it does…) as it doesn’t create symlinks like psd does… and, as @pebcak pointed out, if it is indeed because of the use of bind mounting instead of symlink, then the new $1000 question would be why psd doesn’t use bind mounting ?!
I am not familiar with Bind Mount but from what I understand now (very little indeed) the “actual” data is supposed to be written in the bind directory, which is in this case located in RAM, accomplishing the desired goal of speeding things up and giving the drive some rest…
It seems asd used to operate as psd, i.e. creating simlinks, hence the description on github:
About: Symlinks and syncs user specified dirs to RAM thus reducing HDD/SDD calls and speeding-up the system.
