Hello,
there is another place where cmpxchg is used to "atomically" set 16 bytes (see #9).
This is in the fast write path when appending a file.
In this case, the file length and file timestamps are updated together.
Crash states are possible where the file data has been updated but not the timestamps.
This is obviously just a minor bug but should still be addressed.
Currently, this cannot be realized atomically.
For the strict mode, I propose to just disable this half of the fast write path.
For the relaxed mode, I propose to swap the order, so that the timestamp might be updated without the new file length/data but not vice-versa.
Hello, there is another place where cmpxchg is used to "atomically" set 16 bytes (see #9). This is in the fast write path when appending a file. In this case, the file length and file timestamps are updated together. Crash states are possible where the file data has been updated but not the timestamps. This is obviously just a minor bug but should still be addressed.
Currently, this cannot be realized atomically. For the strict mode, I propose to just disable this half of the fast write path. For the relaxed mode, I propose to swap the order, so that the timestamp might be updated without the new file length/data but not vice-versa.