layer file creation: remove redundant fsync()s

[problame]

The writer.finish() methods already fsync the inode, using VirtualFile::sync_all().

All that the callers need to do is fsync their directory, i.e., the timeline directory.

Note that there's a call in the new compaction code that is apparently dead-at-runtime, so, I couldn't fix up any fsyncs there Link.

Note that layer durability still matters somewhat, even after #5198 which made remote storage authoritative.
We do have the layer file length as an indicator, but no checksums on the layer file contents.
So, a series of overwrites without fsyncs in the middle, plus a subsequent crash, could cause us to end up in a state where the file length matches but the contents are garbage.

part of #6663

[koivunej]

Thanks

[koivunej]

In the grand scheme of things, layer durability probably doesn't matter anymore because the remote storage is authoritative at all times as of #5198. But, let's not break the discipline in this commit.

We currently use the length as the only measure of "layer file is intact" so we would have to come with something for this if we were to drop fsyncs.

[problame]

We currently use the length as the only measure of "layer file is intact" so we would have to come with something for this if we were to drop fsyncs.

Hm, ok, will adjust the PR description.

[problame]

Erm, wait, no. The layer length mechanism would be sufficient to detect if we crashed after writing out a layer into the kernel page cache but before fsyncing.

Then gain, better to be safe here.

[github-actions]

2484 tests run: 2362 passed, 0 failed, 122 skipped (full report)

---

Flaky tests (1)

Postgres 15

• test_compute_pageserver_connection_stress: debug

Code coverage* (full report)

• functions: 28.7% (6937 of 24179 functions)
• lines: 47.2% (42542 of 90143 lines)

* collected from Rust tests only

---

_{The comment gets automatically updated with the latest test results
d46f31e at 2024-03-04T11:29:25.829Z :recycle:}