It seems this isn’t documented anywhere. I’m asking about Electric Eel that uses Docker now, not about the old k3s implementation.
There’s a dedicated tmpfs limit here:
And also total limit for the app at the bottom:
The question is whether the total amount used by app+tmpfs is capped by that value, or just the amount used by app itself and the tmpfs uses the indepedently configured own limit underneath it?
Intuitively one could think that main memory limit would be just for the app, but some research online shows some scarce information that the limit is indeed total and even includes swap space usage too. Someone on some other forums was complaining that this behavior isn’t really explicitly documented in the Docker docs.
My second question would be if tmpfs can make usage of swap file, but if it’s just a regular tmpfs mount then I bet 99% that the answer is yes. Only the documentation about storing secrets. But the documentation at “Installing Custom Applications” says this, which might suggest otherwise: For security purposes, you can store sensitive data like temporary credentials or data in tmpfs instead of writing to disk.
I think that line is confusing because the data in tmpfs will be moved to swap if it’s not actively accessed under memory pressure, thus written to disk, albeit not permanently. So it’s kinda yes it’s true, but not really. I’d change that line to “instead of writing to filesystem”.
This question comes from this discussion where we update docs for Jellyfin for new TrueNAS Scale:
Hi @p0358. Glad to see that doc is getting updated!
We’ve had some internal discussion about it, but ultimately anything I say about the tmpfs behavior would be a guess. As you’ve seen, Docker docs aren’t very helpful on the subject and looking around online I’ve seen both things saying that the tmpfs mount is and is not limited by the overall container restrictions.
Since we’re passing through default docker behavior there, I think the best bet barring extensive testing is to reach out to the docker devs and try to get an answer from the source.
Same thing with the swap question, though I’d note that swap is globally disabled in TrueNAS so that may affect expected behavior for tmpfs mounts in docker containers. I’ll look at softening that line a bit unless we get more specificity–docker docs do suggest tmpfs can be used for sensitive data, but that is a reasonable suggestion.
Ps. TrueNAS is moving to a more explicitly community managed strategy for documenting apps in the Community train, including Jellyfin, starting with 24.10. If anyone working on the project is interested on feeding back the updated procedure, we’d be happy to have the PR GitHub - truenas/documentation: TrueNAS Documentation Hub
Ahh, that seems to be right. Was it always the case? Maybe I confused it with Proxmox’s default behavior there. Could’ve sworn swap was created if boot drive had enough space, but then when I think more about it, something about that memory and recalling how boot drive is laid out doesn’t seem right.
Thanks for pointing that out, I’ll have to update the swap mention in docs as I made it say the opposite thing right now
Hmm, if there’s no swap then that line isn’t so bad I guess, the data wouldn’t actually be written to disk in such case (well unless someone manually enables swap).
But it’s still right to look at the security implications of how much it might be accessible or not. If it’s visible as default tmpfs mount and if that was accessible to root user outside of container, then that’d be not much more safe than just having something in normal fs with path also only accessible to root. Although it’d be right to say that without swap it’d be safe against offline attack rather than online one.
