To protect the file system, we plan to use the OverlayFS feature in Jetpack 6.1.
(Reference: OverlayFS on Root File System)
However, when this feature is enabled, we can no longer operate on files in the main partition area, “/dev/nvme0n1p1,” and all changes are lost upon reboot, which is problematic. For example, we need configuration file changes that alter program behavior to persist after rebooting.
To address this, we are considering mounting the partition area “/dev/nvme0n1p14,” which is allocated around 400MB, to a directory (e.g., /mnt/uda) and storing configuration files and other files that need to persist after reboots.
Would there be any issues using “/dev/nvme0n1p14” as described above?
It is the expected result since this feature is used to protect your rootfs get modified.
Actually, you can disable that feature first and modify the content.
After all required configuration been set, you can enable overlay rootfs.
It seems a custom use case that we’ve not verified.
You can try that and see if there’s any issue.
Some comments related to this, but not a direct answer: If your partition uses a journal, and if the unwritten data (buffer or cache) exists at the moment of power loss, then your new partition will save content which has already flushed to disk, but will still fail to save data which was buffered/cached. In the case of the amount of outstanding buffer/cache exceeding the journal, the filesystem as a whole will also be corrupted and require manual repair (in which case someone picks if more is lost or if perhaps some data recovery service can put it back together).
The only disk which will not lose something in a power loss is the one which writes without cache or buffer. In all cases this will dramatically decrease performance. In the case of solid state drives, this will also dramatically lower the life expectancy of the device.
Normally it wouldn’t matter much, but if you were to use synchronous write, chances are that power consumption will also go up.
A less common option, and one which is quite often not possible, is to write via network to another computer where that other computer is set up for high reliability (e.g., power backup). This is essentially distributing or offloading that function. This works really well on diskless clusters where a master node is the only one with an actual disk.