Sd card:TX2 can‘t save any data on sd card after power down

I meet a very strange problem.
In out program, fwrite() function is used to write a file in sd card on TX2. I find that if the program don’t use fclose() to close the file, any data can’t be saved in the sd card after power down.
32.3.1 BSP and rootfs are used on the TX2.
who meet the same problem and know the reason?

If you write to storage with a cache behind it, then you have to either flush or close (which flushes). It would be expected that some cases of not properly closing the file would result in nothing being written. However, it isn’t clear if you mean the entire SD becomes unwritable, or if you mean you lost just the one file.

Also, some programs may look for a lock file, and if the lock file is still present after an incorrect close, then this is the same as causing the program to think the file is still owned and used by some other program, and so it would be proper to refuse.

Can you give more detail on what is being written, and what exactly is failing? For example, the entire SD card, or just the one file? Is shutdown being correctly performed (e.g., with “sudo shutdown -h now”), or is some other method (such as cutting power) being used for shutdown?

NOTE: This should be moved to the TX2 forum. If you can start the topic in the TX2 forum with those questions being added:
https://forums.developer.nvidia.com/c/agx-autonomous-machines/jetson-embedded-systems/jetson-tx2/81

Hi,

In our case , the TX2 is cut power suddenly, so the program has no chance to flush the file. so the file(not the entire SD) which is being written will lost.

There is nothing you can do about losing data or leaving a stale lock file behind in the case of power cut. Technically, you could mount the drive in synchronous mode. This would write every last byte as it arrives, but would destroy the life of any solid state memory. I would expect very fast device eMMC or SD card failure for a synchronous mount.

In terms of a stale lock file (and I don’t know which issue is really the one you are working with at the moment), that file lock location could be put in a ramdisk mount instead of on persistent memory. A ramdisk would go away upon power reset. You’d still lose data, but the lock file would be wiped upon restart.

Alternatively, for the stale lock file issue (if that is your issue), then you could simply make a script which, upon boot, prior to starting your program, the lock file is forcibly removed should it exist.