Qt World Summit: Register Today!

Embedded Qt, Power Cycling & SDCards - how to prevent SDCard corruption?

  • Hi...

    We have a Qt application in a device running embedded Linux which may be power cycled daily by the end user. So far, in the lab, we have see a few corrupted SDCards and suspect it is our device (i.e. not the computer) doing the corruption.

    We store our Qt binaries on the SDCard along with our SQL data base which we access through Qt/SQL. We also use a Qt *.ini file which can get modified when the device is first powered on.

    So, what might be going on here? What event(s) can cause SDCard corruption.

    Also, what do people do to avoid such problems?


  • Here's another question:

    1. Exactly when is a file open when written to by Qt?

  • Here's another question:

    1. Does Qt open a file for READING -and- WRITING or is it smart enough to see that a file is only read from and, therefore, only open it for READING?

  • A [[Doc:QFile]] is opened in exact the mode you tell it.

    For other files: have a look at the source code.

    And keep in mind, that the handling of files for SQLite databases is completely out of control of Qt, as this is entirely handled by the SQLite libs.

  • bq. And keep in mind, that the handling of files for SQLite databases is completely out of control of Qt, as this is entirely handled by the SQLite libs.

    Ah! Obviously - I'm so in need of coffee today.

    Ok, so let me be more specific...

    We have been using an *.ini file to keep certain configuration features for our Qt application. Recently, we created a new application just to change certain entries of the *.ini file. Today we accused each other of editing the *.ini file and putting it in alphabetical order. When no one confessed, we assumed that our Qt application sorted the file while it was changing it's content. Is that possible?

    Now I am wondering if I should be executing a Linux "sync" command between the two Qt programs just to make sure there is nothing being cached.

    I think in the end that running Qt on an embedded target with an SDCard which is being written to is going to be tricky. That is, we must constantly be closing files and flushing buffers in order to mitigate our exposure to unexpected power down events and unexpected SDCard pulls.

    Do any have thoughts on this subject?


  • If you do use the .ini file by means of [[Doc:QSettings]] and you do modify the QSettings object, the file is written by Qt. Chances are good, that it is rewritten completely and that the keys are "in order" then. It's ok to use the .ini file from different applications simultaneusly:

    bq. from QSettings docs:
    QSettings can safely be used from different processes (which can be different instances of your application running at the same time or different applications altogether) to read and write to the same system locations. It uses advisory file locking and a smart merging algorithm to ensure data integrity. Note that sync() imports changes made by other processes (in addition to writing the changes from this QSettings).

    The other application must use file locking too, of course.

    A manual OS level sync shouldn't be necessary between access to the ini file from on application after another one has quit, that's handled by the OS. The final sync is needed to flush the cache before the power goes down (or the kernel reboots).

    An unexpected power down can crash any mass file storage, regardless whether it's an SD card or a hard disc. One possible solution coulde be to mount the SD card in a "synchronous" mode, which causes the writes to be synced to the card immediately. Although I suspect this to slow down the speed of your system dramatically, especially in case of only small changes. That's caused by the way the data is written to the memory cells (a block must be erased completely, and then written again).

Log in to reply