Hello, 1. I am using Tarsnap within a jail on a host with 2GB of RAM. The host is running FreeBSD 11.0-RELEASE-p1. Within the jail, uname -UK gives '1100122 1100122', so its userland is in sync with the host’s kernel.
2. The Tarsnap key file has been generated (on a different host) with --passphrase-mem 268435456, so decrypting the key file should not require more than 256 MB of memory. 3. Within the jail, ulimit -a gives: number of pseudoterminals (-P) unlimited socket buffer size (bytes, -b) unlimited core file size (blocks, -c) unlimited data seg size (kbytes, -d) 33554432 file size (blocks, -f) unlimited max kqueues (-k) unlimited max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 2048 pipe size (512 bytes, -p) 1 stack size (kbytes, -s) 524288 cpu time (seconds, -t) unlimited max user processes (-u) 6656 virtual memory (kbytes, -v) unlimited swap size (kbytes, -w) unlimited 4. The host uses ZFS. When the host has been running for a long time, such that there is significant data in the ZFS ARC, top gives the following memory stats: Mem: 11M Active, 64M Inact, 1804M Wired, 82M Free ARC: 1205M Total, 640M MFU, 229M MRU, 1060K Anon, 19M Header, 317M Other Swap: 4096M Total, 17M Used, 4079M Free 5. Given that the ZFS ARC is able to release memory, and given also the free swap space, a process (e.g. tarsnap) should have no trouble allocating 256 MB of memory to decrypt the key file. The ulimit data size (see 3, above) is not a limiting factor. 6. However: # tarsnap --keyfile tarsnap.key --fsck Please enter passphrase for keyfile tarsnap.key: tarsnap: Decrypting file would require too much memory tarsnap: Error decrypting key file: tarsnap.key tarsnap: Cannot read key file: tarsnap.key 7. Interactively reducing the size of the ZFS ARC with, for example, ‘sysctl vfs.zfs.arc_max=512000000‘ doesn’t help, perhaps because FreeBSD seems still to count the released ARC memory as wired. (top does show the ~700 MB reduction in ARC size, however.) 8. However, if I reboot the host, and then immediately run the tarsnap --fsck command within the jail, it succeeds: # top -bu -d1 -s1 | head -n6 | tail -n3 Mem: 44M Active, 7344K Inact, 159M Wired, 1750M Free ARC: 60M Total, 17M MFU, 39M MRU, 928K Anon, 570K Header, 2821K Other Swap: 4096M Total, 4096M Free # tarsnap --keyfile tarsnap.key --fsck Please enter passphrase for keyfile tarsnap.key: Phase 1: Verifying metadata validity Phase 2: Verifying metadata/metaindex consistency Phase 3: Reading chunk list Phase 4: Verifying archive completeness Archive 1/450... Archive 2/450... Archive 3/450... ... 9. Hypothesis: Tarsnap/scrypt is erroneously deciding that there is insufficient memory available on the system in point (6) above. (Either that, or I am doing something very silly.) I should welcome any suggestions as to how I may reliably fsck (or perform other operations needing the passphrased key file) without first having to reboot the host. (My regular tarsnap backups are unaffected, since those use a non-passphrased write-only key.) Many thanks in advance. -- Daniel Neades