tarsnap: Decrypting file would require too much memory

[Daniel Neades <djn@araxis.com>]

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