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.
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.