LisPi on Nostr: nprofile1q…utslx akko Normal Mikoto :kagami_shrug: :gekota: ...
nprofile1qy2hwumn8ghj7un9d3shjtnddaehgu3wwp6kyqpq0cq07ulfyc7y2l8rczk9s36g8j65tq3m6xk9us8hr3ua4ktfmaqqeutslx (nprofile…tslx) akko (nprofile…wssg) Normal Mikoto :kagami_shrug: :gekota: (nprofile…nc0q) https://en.wikipedia.org/wiki/Ext3#Journaling_levels
In-place modification and a crash can lead to data corruption with only metadata journaling. Full data journaling will prevent that.
The modification is only committed once journaling it is done, so if there is a crash in the meantime, that isn't a problem.
This does *not* protect against the program sending multiple writes to update file state instead of a single large one and a crash occuring in-between though. But neither does btrfs protect against that sort of consistency issue.
To protect against that, proper transactionality as offered by LMBD or SQLite is required.
In-place modification and a crash can lead to data corruption with only metadata journaling. Full data journaling will prevent that.
The modification is only committed once journaling it is done, so if there is a crash in the meantime, that isn't a problem.
This does *not* protect against the program sending multiple writes to update file state instead of a single large one and a crash occuring in-between though. But neither does btrfs protect against that sort of consistency issue.
To protect against that, proper transactionality as offered by LMBD or SQLite is required.