You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To avoid (or at least reduce) database file corruption on system failures like a hard power off, having means to enforce a storage sync via fsync() would be great.
Background
I am currently using JsonDB on a Raspberry Pi and the database file is stored in an ecryptfs encrypted folder. In this scenario a hard power-off after a write to the JsonDB results in reproducable file corruptions. I.e. when mounted again the database file is corrupt and can't be decrypted by ecryptfs correctly. Since ecryptfs is a stacked filesystem, my explanation is that the OS does some additional buffering here and postpones the actual write to storage longer than it does e.g. when running directly on a Ext4 filesystem.
I already prepared a patch which I would be happy to contribute.
The text was updated successfully, but these errors were encountered:
drproktor
added a commit
to drproktor/node-json-db
that referenced
this issue
Mar 10, 2022
To avoid (or at least reduce) database file corruption on system failures like a hard power off, having means to enforce a storage sync via fsync() would be great.
Background
I am currently using JsonDB on a Raspberry Pi and the database file is stored in an
ecryptfs
encrypted folder. In this scenario a hard power-off after a write to the JsonDB results in reproducable file corruptions. I.e. when mounted again the database file is corrupt and can't be decrypted byecryptfs
correctly. Sinceecryptfs
is a stacked filesystem, my explanation is that the OS does some additional buffering here and postpones the actual write to storage longer than it does e.g. when running directly on a Ext4 filesystem.I already prepared a patch which I would be happy to contribute.
The text was updated successfully, but these errors were encountered: