Profile-sync-daemon

Since the profile(s), browser cache, etc. are relocated into tmpfs (RAM disk), the corresponding I/O associated with using the browser is also redirected from the physical drive to RAM, thus reducing wear to the physical drive and also greatly improving browser speed and responsiveness.

Related articles

(psd) is a tiny pseudo-daemon designed to manage browser profile(s) in tmpfs and to periodically sync back to the physical disc (HDD/SSD). This is accomplished by an innovative use of rsync to maintain synchronization between a tmpfs copy and media-bound backup of the browser profile(s). Additionally, psd features several crash recovery features.

The design goals and benefits of psd are:

  1. Transparent user experience
  2. Reduced wear to physical drives
  3. Speed

Installation

Install the package.

Configuration

When you run psd for the first time, it will create $XDG_CONFIG_HOME/psd/psd.conf (referred to hereafter as the configuration file) which contains all settings. You can run the command before using to create this file without starting synchronization.

  • Optionally enable the use of overlayfs to improve sync speed and to use a smaller memory footprint. Do this in the variable. The user will require sudo rights to /usr/bin/psd-overlay-helper to use this option and the kernel must support overlayfs version 22 or higher. See #Overlayfs mode for additional details.
  • Optionally define which browsers are to be managed in the array. If none are defined, the default is all detected browsers.
  • Optionally disable the use of crash-recovery snapshots (not recommended). Do this in the variable.
  • Optionally define the number of crash-recovery snapshots to keep. Do this in the variable.

Example: Let us say that Chromium, Opera and Midori are installed but only Chromium and Opera are to be sync'ed to tmpfs since the user keeps Midori as a backup browser and it is seldom used:

BROWSERS=(chromium opera)

Beginning with version 5.54 of psd, native support for overlayfs is included. This feature requires at least a Linux kernel version of 3.18.0 or greater.

Supported browsers

Currently, the following browsers are auto-detected and managed:

Usage

Start/enable the user unit. Additionally, a provided resync-timer will run an hourly resync from tmpfs back to the disk. The resync-timer is started automatically with so there is no need to manually start the timer.

Preview (parse) mode

Run to view what psd will do/is doing based on $XDG_CONFIG_HOME/psd/psd.conf. It will also provide useful information such as profile size, paths, and if any recovery snapshots have been created.

Tips and tricks

Sync at more frequent intervals

The package provided re-sync timer triggers once per hour. Users may optionally redefine this behavior simply by extending the systemd unit. The example below changes the timer to sync once every ten minutes (note that needs to be cleared before being re-assigned ):

See for additional options.

Overlayfs mode

Overlayfs is a simple union file-system mainlined in the Linux kernel version 3.18.0. Starting with psd version 5.54, overlayfs can be used to reduce the memory footprint of psd's tmpfs space and to speed up sync and unsync operations. The magic is in how the overlay mount only writes out data that has changed rather than the entire profile. The same recovery features psd uses in its default mode are also active when running in overlayfs mode. Overlayfs mode is enabled by uncommenting the USE_OVERLAYFS="yes" line in $XDG_CONFIG_HOME/psd/psd.conf followed by a restart of the daemon.

Since version 6.05 of psd, users wanting to take advantage of this mode MUST have sudo rights (without password prompt) to /usr/bin/psd-overlay-helper or global sudo rights. The following line in will supply a user with these rights. Add it using visudo:

username ALL=(ALL) NOPASSWD: /usr/bin/psd-overlay-helper

See the example in the PREVIEW MODE section above which shows a system using overlayfs to illustrate the memory savings that can be achieved. Note the "overlayfs size" report compared to the total "profile size" report for each profile. Be aware that these numbers will change depending on how much data is written to the profile, but in common use cases the overlayfs size will always be less than the profile size.

The way overlayfs works is to mount a read-only base copy (browser-back-ovfs) of the profile, and manage the new data on top of that. In order to avoid resyncing to the read-only file system, a copy is used instead. So using overlayfs is a trade off: faster initial sync times and less memory usage vs. disk space in the home dir.

Allocate more memory to accommodate profiles in /run/user/xxxx

The standard way of controlling the size of /run/user is the RuntimeDirectorySize directive in (see for more). By default, 10% of physical memory is used but one can increase it safely. Remember that tmpfs only consumes what is actually used; the number specified here is just a maximum allowed.

Snapshots

Odds are the "last good" backup of your browser profiles is just fine still sitting happily on your filesystem. Upon restarting psd (on a reboot for example), a check is performed to see if the symlink to the tmpfs copy of your profile is valid. If it is invalid, psd will snapshot the "last good" backup before it rotates it back into place. This is more for a sanity check that psd did no harm and that any data loss was a function of something else.

You will find the snapshot in the same directory as the browser profile and it will contain a date-time-stamp that corresponds to the time at which the recovery took place. For example, chromium will be -- of course, the date_time suffix will be different for you.

To restore your snapshots:

  • Stop the user unit.
  • Confirm that there is no symlink to the tmpfs browser profile directory. If there is, psd did not stop correctly for other reasons.
  • Move the "bad" copy of the profile to a backup (do not blindly delete anything).
  • Copy the snapshot directory to the name that browser expects.

Example using Chromium:

$ mv ~/.config/chromium ~/.config/chromium-bad
$ cp -a ~/.config/chromium-backup-crashrecovery-20130912_153310 ~/.config/chromium

At this point you can launch chromium which will use the backup snapshot you just copied into place. If all is well, close the browser and restart psd. You may safely delete at this point.

Clean all the snapshot with the clean mode

Running will delete ALL recovery snapshots that have accumulated. Run this only if you are sure that you want to delete them.

Support

Post in the discussion thread with comments or concerns.

gollark: They can also contain rational numbers if they want to.
gollark: The base is a pointer to another float, and Macron floats are actually 256 bits.
gollark: Further evidence of LyricLy being `-84 FrameControl { version: 0, ftype: Management(Beacon), to_ds: false, from_ds: false, more_fragments: false, retry: false, more_data: false }`.
gollark: Macron floats are just arbitrary real numbers encoded in finite amounts of memory via certain anomalous pigeonhole principle violations.
gollark: I totally didn't not read that.

See also
This article is issued from Archlinux. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.