ASD anything-sync-daemon... is it actually working? edit: Symbolic Links - Bind mount?

Hey

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 ?

I would be very grateful for any advice :slight_smile:

Cheers !!

(@pebcak cause I think you’re using asd too…)

2 Likes

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/… ? :thinking:

Looks like you can do it without ASD :
https://wiki.archlinux.org/title/Chromium#Cache_in_tmpfs

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.

My bad, I’m so used to the cache being deleted when I closed Firefox, I forgot you would need to save it.

1 Like

Thank you both a lot for your time.

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.

Me too.
I do actually use the method you have linked to to mount Chromium’s cache to /tmpfs.

Thanks a lot to all for your concern !

Yep I did indeed rtfm…

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.

As well,

1.3 Turn off the disk cache

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 ?! :stuck_out_tongue_closed_eyes:

I think asd make the links between the target, the sync target and the tmpfs target, it doesn’t need to create symlinks.

I guess you’re right and as @pebcak pointed out,

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.

but then, the last version implemented bind mounting, specifying:

This will avoid symlinking issues and race conditions which leave the directory in inconsistent state.

So I presume everything is working as it should, I still just don’t really understand bind mounting :upside_down_face:

EDIT @pebcak @vazicebon @Stagger_Lee
I guess here is the definitive answer : https://github.com/graysky2/anything-sync-daemon/issues/87#issuecomment-1946146861
Cheers !

2 Likes

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.