Jetson Orin Nano currently utilizes an SSD with NVMe protocol as its file storage system, in Ext4 format. In our usage scenario, we usually opt to directly disconnect the power cord without performing a proper shutdown, as it is inconvenient to do so. In this case, does frequent power disconnection pose a risk of file system damage? Are there any solutions available to ensure the integrity of the Jetson file system?
Hi,
That’s possible, but I think SSD should be more robust to such issues than HDD, as they do not have mechanical structures.
I think you have to address it from the hardware level (not disconnecting power supplies directly), but not software level.
Or you may also consider enabling rootfs redundancy:
https://docs.nvidia.com/jetson/archives/r35.3.1/DeveloperGuide/text/SD/RootFileSystem.html#root-file-system-redundancy
You might find this useful:
https://forums.developer.nvidia.com/t/tuning-linux-on-jetson-nano-for-better-data-reliability-in-power-failure-scenario/252664/5
What settings can we configure to set the root file system of Jetson Orin Nano to romfs, which simulates a file system in memory? This way, we can ensure automatic recovery after each power outage.
Does this mean the system is in read-only mode?
I have not experimented with all of the possibilities. The first thing you’d be interested in knowing about is loopback. When loopback covers a memory device, the device can look like another device. A file can be covered by loopback, and then the file is then treated like mass storage (a partition or entire disk instead of a file). Loopback can also make USB pretend the Jetson is a network device via the Gadget system. This is not in and of itself what you are asking, but it is a useful tool.
The initrd (initial ramdisk) sometimes used in boot is in fact purely RAM, but organized as a filesystem (very primitive, without the permissions and metadata you would expect of a full filesystem, but it is very easy to use and makes an adapter to filesystem types the native kernel might not support because it can have kernel modules in it which do support those other filesystems).
The zram is often used for swap, and is also in RAM, but the “z” implies it also uses compression.
I couldn’t tell you what all of the ways of doing this are, but most of those have no resilience to power failure. In fact, zram is useful as swap in part just because of that…swap does not need to be remembered between boots, but is high performance, efficient, and can be both read and written. One would probably start by looking up the kernel documents on this since the kernel supports this (in combination with user space tools).
What you’re really looking for seems to be OverlayFS. OverlayFS tends to be used on kiosks. If you have an underlying read-only filesystem, then RAM “overlays” that for any writing or editing. If you edit a file, then the edits show up from the RAM, but the underlying system has no change. Upon power loss or reboot the RAM layer is repopulated with the underlying read-only filesystem as that content is accessed. There have been a number of people on the forums though who have had troubles making this actually work on a Jetson. There is likely some initrd “Jedi trickery” needed, along with the kernel support.
Note that all of these will lose any edits or changes if power is lost without being written first. To not lose data, as a guarantee, means you must write synchronously. There can be no cache, and there can be no buffer. For solid state memory this also implies device failure far sooner than normal. For every device this means extremely poor performance.
You could increase the journal size. This means you’d be able to lose more data without corruption. You still lose data, the changes get truncated, but it does not require user intervention for repair. This is the nature of 100% of all storage devices and filesystems on all operating systems. Read-only memory is the only memory which is not harmed in any way from a sudden power loss.
The normal operation is not read-only. This seldom works well. However, there are some tricks which might help depending on circumstances. You could for example consider a second storage device for content you expect to be heavily written to. As an example, suppose you have a camera and are recording video continuously near the limit of the device’s storage speed. There is no way that even a large journal would prevent corruption. You could mount an alternate storage device, and then record to that alternate device. The main operating system content might lose something tiny, but it is unlikely it would ever corrupt if most usage is to a different storage device. The video would be lost, the operating system would survive.
Normally a ROM is read-only memory. So a ROM cannot suffer from data truncation…nothing is being written, nor is anything cached. A ROM could suffer device failure from power spikes, but unless the ROM actually dies, nothing will ever be lost. Sadly, also, nothing will ever be written beyond whatever is on it. An EEPROM is “flashed”, but not continuously written to the way a disk is written to, and you could alter it at a later date, but unless power is lost during write of the device, then the EEPROM would be safe.
I don’t think a Nano supports it, but there are also A/B partition schemes whereby if the normal A partition fails, then the Jetson instead boots to the B partition. This tends to be available on eMMC models of newer hardware. I don’t know if a TX2 supports that, but it might (a Nano is a TX1, and non-eMMC models definitely don’t support that in a TX1).
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.