No, something changed with recent chromium release. I too am not able to have passwords get saved.
This was not related to chromium but to a corrupted database, see: https://wiki.archlinux.org/title/Chromi … d_database
]]>It shows how to set interval, not how to disable it completely.
If you set 1000000 minutes, it is like deactivating it.
]]>]]>Is there a way to only sync on shutdown ? Disable hourly sync ?
I came upon this by checking performance loss with LUKS2 on modern & fast NVME's.
Now I am trying to reduce the workload on my NVME and used PSD + "browser.cache.disk.parent_directory" to move Firefox into RAM.
Additionally ZRAM (in RAM) instead of ZSWAP.
Because why not make use of those 32GB of RAM
Is it possible to support LibreWolf (a Firefox fork)? => https://librewolf.net
The profile is located in ~/.librewolf/
Thank you very much and have a nice day.
]]>I've installed the package this morning, that's the output of `journalctl --user-unit psd.service`:
Apr 01 11:19:08 thinkpad systemd[982]: Starting Profile-sync-daemon...
Apr 01 11:19:08 thinkpad profile-sync-daemon[989]: psd startup check successful
Apr 01 11:19:08 thinkpad systemd[982]: Finished Profile-sync-daemon.
And that's `psd preview`:
Profile-sync-daemon v6.48
systemd service: active
resync-timer: active
sync on sleep: disabled
use overlayfs: disabled
Psd will manage the following per /home/anon/.config/psd/.psd.conf:
browser/psname: firefox/firefox
owner/group id: anon/1000
sync target: /home/anon/.mozilla/firefox/d1ef0kop.default
tmpfs dir: /run/user/1000/psd/anon-firefox-d1ef0kop.default
profile size: 13M
recovery dirs: none
browser/psname: firefox/firefox
owner/group id: anon/1000
sync target: /home/anon/.mozilla/firefox/4aogg4vd.default-release
tmpfs dir: /run/user/1000/psd/anon-firefox-4aogg4vd.default-release
profile size: 196M
recovery dirs: none
My browser is Firefox, how can I verify that profile is on RAM?
]]>What would specifying a value for block-size do functionally? What is wrong without doing it? Not much on the option in the man page.
To be sure we're on the same page, I've establshed some context first.
The tool is partly to reduce wear on drives (writes to SSDs) as browsers are notorious for this. When updating the copy on the SSD, you'd like to write only the changed portions of a file. Changes come into basic types: insertion/deletion, and mere change in place. Insertion/deletion naturally shift everything after in the file, requiring a rewrite of everything after that point, so there's little that can be done to reduce writes in this case. But change in place only requires rewriting the SSD pages containing the changes.
Rsync has an in-place delta update mode that breaks the destination file into a series of blocks of equal size, then skips rewriting any that need no change. By default the block size is a fraction of the file, down to 700 bytes at minimum, and up to 131K. Rsync's selection of block size is optimized to reduce network traffic when updating over a slow link.
The default block size is almost always either not an even division of the SSD page size, or larger than an SSD page size. This means that even when a single byte in a block was changed, it can overlap two or more SSD pages, causing unnecessary writes (write amplification). By using a block size that is a clean division of a page size (e.g. 512, 1024, 2048, 4096), this ensures that this amplification won't occur; no blocks in the destination file will overlap SSD page boundaries.
One caveat, I haven't looked into detail how you handle multiple snapshots. If they use hardlinks (to allow sharing of data between snapshots) I don't think rsync could do delta updates in place, since those would modify the same file in other snapshots if they linked to it.
This page by the rsync author has a nice description of the algorithm: https://rsync.samba.org/tech_report/
]]>--block-size=SIZE, -B
This forces the block size used in rsync's delta-transfer algorithm to a fixed value. It is normally selected based on the size of each file being updated. See the technical report for details.Beginning in 3.2.3 the SIZE can be specified with a suffix as detailed in the --max-size option. Older versions only accepted a byte count.