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
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: