On Azure-files it seems that ftruncates are much more expensive than would have been expected.
There was some work to minimise them in #7828 but it would be good to eliminate them from the rollback path as well.
The key invariant that we need is that .committed files are the same on all nodes to simplify operations.
So we need an eventual ftruncate on the .committed file to ensure that the file matches on backups which get these replicated.
One approach will be to just write zeros at the end of the file, but that entails a tradeoff between the latency of the ftruncate and the latency of the eventual sync of the zeros.
On Azure-files it seems that ftruncates are much more expensive than would have been expected.
There was some work to minimise them in #7828 but it would be good to eliminate them from the rollback path as well.
The key invariant that we need is that .committed files are the same on all nodes to simplify operations.
So we need an eventual ftruncate on the .committed file to ensure that the file matches on backups which get these replicated.
One approach will be to just write zeros at the end of the file, but that entails a tradeoff between the latency of the ftruncate and the latency of the eventual sync of the zeros.