C08-MT: Yes

Archived previous-definition assessment — revision 4.72. Retired in 5.73; excluded from the active matrix and counts. This historical verdict is not a current assessment.

Rationale

The native daemon supports selecting its virtual-filesystem directory. In ARCH_PORTDUINO, FSCom maps to the host-backed PortduinoFS; NodeDB writes can therefore succeed on a writable volatile filesystem instead of durable flash. Select the complete VFS on private noswap tmpfs, disable persistent logging/exports and host memory persistence, and seed only clean static provisioning after cold start. Learned identities, timestamps and other caches may exist in RAM while the node runs, but no persistent traffic history is required in this bounded deployment. This resolves the earlier missing-filesystem objection: writes are supported and successful, not suppressed by a power or storage failure. It is an explicit host deployment capability, not the ordinary embedded default or absence of live state.

Assessment method

Native filesystem/source and official deployment documentation; no radio or filesystem experiment

Source context

Meshtastic native VFS configuration, FSCommon/NodeDB and Linux tmpfs

Outstanding qualification

Verify the effective VFS root and all hot/warm/history/backup files remain inside the volatile mount; TraceFile and JSONFile empty, stdout/stderr not persisted, no client database, MQTT or remote exporter. Confirm swap/hibernation/core dumps and snapshots do not persist process or tmpfs pages. Fail startup if volatile storage is unavailable. Trace writes under decoded and opaque LoRa traffic, cold-start from static provisioning, and verify forwarding resumes without restoring learned histories. No such experiment was executed here.

Public sources

Editorial evidence references

The following identifiers refer to research records not included in this public package; they are not public links.

round131-sources.json
round124.html