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,
I discovered another bug in the fast write path.
The bug occurs when modifying existing file contents if the region does not cross page bounds and the file system is in relaxed mode.
In this case, the file timestamp is only written after the data.
Therefore, crash states are possible where the data has been modified but the timestamp stays the same.
I think the most reasonable way to fix this is to move the timestamp update before the data update.
In this case, it is possible that the file is unmodified but the timestamp has been updated.
However, I think a too young timestamp is better than a too old one.
Otherwise, we could just permanently disable the fast write path but I think this is somewhat of an overreaction.
The text was updated successfully, but these errors were encountered:
Hello,
I discovered another bug in the fast write path.
The bug occurs when modifying existing file contents if the region does not cross page bounds and the file system is in relaxed mode.
In this case, the file timestamp is only written after the data.
Therefore, crash states are possible where the data has been modified but the timestamp stays the same.
I think the most reasonable way to fix this is to move the timestamp update before the data update.
In this case, it is possible that the file is unmodified but the timestamp has been updated.
However, I think a too young timestamp is better than a too old one.
Otherwise, we could just permanently disable the fast write path but I think this is somewhat of an overreaction.
The text was updated successfully, but these errors were encountered: