Missing calls to fsync() can leave systems with no valid partition table

[DemiMarie]

Operating systems do not guarantee that writes reach disk in the same order in which they are made, unless O_DIRECT|O_SYNC is used or explicit calls to a flush function (such as fsync() on Unix-like systems or FlushFileBuffers() on Windows) are made and succeed. Therefore, it is possible that both the writes to the primary and backup partition tables can partially succeed, leaving the system with no valid partition table and therefore unbootable.

The solution is to add the needed flushing where necessary. User code cannot provide this flushing because no user code runs in the places where barriers are needed.

[cecton]

Hello and welcome 👋

Sorry for the delay I lost track of time.

You're absolutely right about the risks related to out-of-order or partial writes and the need for explicit flushing to ensure on-disk consistency, especially with GPT partition tables. However, this library deliberately abstracts over std::io::Write and doesn't assume knowledge of the underlying storage layer. As a result, it cannot and does not attempt to call system-level flush functions like fsync() or FlushFileBuffers() internally.

This design choice delegates responsibility for durability guarantees to the caller. If you're writing to a File, you must explicitly flush it after write operations that must be persisted.

There was a CLI binary in the past that may have handled this, but it has been removed and is no longer maintained.

I'll close this issue for now but feel free to re-open it or start a new discussion if you think I've missed something.

[DemiMarie]

You need to call fsync() between write operations done by the library. In particular, using an arbitrary std::io::Write is not safe.

I think it would make more sense to provide platform-specific implementations, or at least an extension trait that callers must implement.

[cecton]

The user calling fsync() after they called Gpt::write_into() isn't sufficient? It's the only write method they need to call, everything is done in memory.

[cecton]

If the user opens a file with O_DIRECT|O_SYNC, would that be safe then? Maybe I can just document that in the Gpt::write_into() function.

[DemiMarie]

The user calling fsync() after they called Gpt::write_into() isn't sufficient? It's the only write method they need to call, everything is done in memory.

I don’t think so. There need to be write barriers to ensure that the primary GPT is not overwritten before the backup GPT has been synced and visa versa. I would fsync immediately after opening the device, but then O_DIRECT|O_SYNC might be okay.

[cecton]

After reviewing how the gpt crate handles this (or doesn’t), I’m leaning toward a solution where gptman doesn’t write directly to a std::io::Write implementation at all.

Instead, I plan to change the API to return two raw buffers: one for the primary GPT and one for the backup GPT, along with their intended sector offsets and any relevant metadata like sector size. This shifts the responsibility of writing — including flushing with fsync() and handling alignment — to the user.

Here’s the reasoning:

• Durability is system-specific: Proper persistence depends heavily on the OS, filesystem, block device, and hardware caching policies. Trying to get fsync() and alignment right inside a portable library is a deep and fragile rabbit hole.
• Separation of concerns: Users of gptman are likely writing to raw block devices or images and will often know the exact durability and alignment constraints they need (e.g. using O_DIRECT, aligning to 512/4096-byte sectors, etc.).
• Avoids false confidence: If fsync() were called internally, it could give users a misleading sense of safety even if other flushing steps are still missing.
• Unpredictable write patterns: The serialization process (e.g. using serde) likely performs many small writes internally. Without controlling this directly, it's hard to ensure atomic or aligned I/O, especially on real devices.

The downside is that this approach raises the risk of misuse, so I’ll make sure to document everything clearly: sector alignment, buffer offsets, durability requirements, and examples showing how to write these buffers safely (e.g. to /dev/sdX).

I might also consider offering optional utilities or helper functions for users who want higher-level I/O handling with safety features included.

What do you think of this approach?

Somewhat related issue in gpt: Quyzi/gpt#95

[DemiMarie]

I think this makes sense.