1

I run a Raspberry Pi as a TOR node and use an SD card. The last SD card died, probably due to too much data being written to it.

I'm already using the setting

AvoidDiskWrites 1

So I've set up Raspbian with two read-only filesystems (boot and rootfs).

/var/log is a tmpfs, I have a file /var/log/tor/notices.log where TOR can write to.

I have one writable filesystem which is mounted to /var/lib/tor, because I've seen that TOR is writing to that directory.

That's the files there are:

  /var/lib/tor
  
    cached-certs
    cached-consensus
    cached-descriptors
    cached-descriptors.new
    cached-microdesc-consensus
    cached-microdescs
    cached-microdescs.new
    fingerprint
    lock
    state
  
    cached-status/
    
    keys/ed25519_master_id_public_key
    keys/ed25519_master_id_secret_key
    keys/ed25519_signing_cert
    keys/ed25519_signing_secret_key
    keys/secret_id_key
    keys/secret_onion_key
    keys/secret_onion_key_ntor
    keys/secret_onion_key_ntor.old
    keys/secret_onion_key.old
  
    stats/dirreq-stats
    stats/hidserv-stats

Now I see via /sys/fs/ext4/mmcblk0p3/lifetime_write_kbytes that there's quite some amount of data continuously written to that folder.

The files which get updated often are

cached-consensus
cached-descriptors
cached-descriptors.new
cached-microdesc-consensus
cached-microdescs.new
lock
state

And cached-descriptors is by far the biggest.

I'd like to have that data written to a tmpfs, if possible.

Questions

Do those files need to be persistent (e.g. for sure fingerprint and everything in folder keys, but they don't change during runtime), or is it okay if I have them in a tmpfs.

I could not find anything in the relay documentation.

2
  • 1
    Not a direct answer, but you might want to take a look at setting AvoidDiskWrites 1 in your torrc. "If non-zero, try to write to disk less frequently than we would otherwise. This is useful when running on flash memory or other media that support only a limited number of writes."
    – cacahuatl
    Mar 1, 2018 at 19:53
  • I'm already using this setting, but have been unaware of it (old configuration). Thanks for mentioning, I'll add it to my post.
    – radix
    Mar 2, 2018 at 15:20

1 Answer 1

1

For a relay, the only things that are really important to persist are the keys and config.

The state and descriptors might update frequently, the only issue with not persisting them would be that each time it started it would end up having to redownload the entire consensus directly from the directory authorities.

Depending on how often you restart the device (I.E. that the tmpfs filesystem is created anew with the files no longer present) this might be wasteful, but for most relay uptimes it's probably not too much of a problem.

There have been previous projects that just create a Tor relay with a entirely RAM backed filesystem, so that no long-term storage is required. Projects like tor-ramdisk, in that case they just keep the relays identity and config. While it's not targeted at RPis, it might give you ideas of how to approach it in your own project.

3
  • Thanks. Maybe add the /var/lib/tor/fingerprint to the answer - I'm sure that's also necessary. I'm testing and if it works I'll accept the answer and add some details of the approach to my question.
    – radix
    Mar 6, 2018 at 23:08
  • Fingerprint is derived from the key material, not the other way around so it shouldn't be too necessary.
    – cacahuatl
    Mar 6, 2018 at 23:18
  • okay, thanks for clarifying. Basically working as you said. I'm still testing, and I've got a [follow-up question[(tor.stackexchange.com/questions/16824/…) regarding the usage of the old keys that have been in use for some years.
    – radix
    Mar 8, 2018 at 21:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .