I believe I've identified a potential for corruption to occur in the configuration database and I'd like confirmation before submitting a bug or PR (time permitting).
I was hoping to use the new API to automate config backups and to remove the mount/copy step when restoring but, unless I'm missing something, it appears as though config operations (save/backup/upload) in the new middleware layer are being performed as file copies instead of DB transactions. If the config is being written to when one of these calls is made then corruption will occur.
SQLite v3.6.11+ implements a backup API which is supported by the sqlite3 module in the python v3.7+ stdlib. Unfortunately FreeNAS 11.2 only packages python v3.6.5 but one could still make use of the backup API via a system call to the SQLite shell, more detail on which can be found in my previous post about using it from the CLI or with cron.
I was hoping to use the new API to automate config backups and to remove the mount/copy step when restoring but, unless I'm missing something, it appears as though config operations (save/backup/upload) in the new middleware layer are being performed as file copies instead of DB transactions. If the config is being written to when one of these calls is made then corruption will occur.
SQLite v3.6.11+ implements a backup API which is supported by the sqlite3 module in the python v3.7+ stdlib. Unfortunately FreeNAS 11.2 only packages python v3.6.5 but one could still make use of the backup API via a system call to the SQLite shell, more detail on which can be found in my previous post about using it from the CLI or with cron.
Last edited:
