-
![](https://statics.udongein.xyz/udongein/89a3af4e519d0c0dbf6e50f57ee017e68f527907148294391537fce3e9124274.jpg?name=e7806d404bd75555.jpg)
@ LisPi
2025-02-12 07:58:03
nostr:nprofile1qy2hwumn8ghj7un9d3shjtnddaehgu3wwp6kyqpq0cq07ulfyc7y2l8rczk9s36g8j65tq3m6xk9us8hr3ua4ktfmaqqeutslx nostr:nprofile1qy2hwumn8ghj7un9d3shjtnddaehgu3wwp6kyqpqxnwyhs2feq29my98mj7ak0utyrv00zfy9leugtzwd5e0jkxdy6fq72wssg nostr:nprofile1qy2hwumn8ghj7un9d3shjtnddaehgu3wwp6kyqpq8lwzqdwuxu0u8qsh6fchpdx7g8l3fgaalwr95c7xvlm4yt0rm67sx9nc0q 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.