Comment by scottlamb
7 years ago
That sentence's language can be improved then if a sufficiently determined kernel developer (not sure I'd say "reasonable" but whatever) can misread that sentence in that way (while ignoring the entire "RATIONALE" section). But what value is a guarantee that it's transferred to the storage device and not that it's actually committed to permanent storage? If someone's best argument is that they correctly provide a completely useless guarantee and that there's nothing that provides the guarantee that people actually need for real work, they're on pretty shaky footing.
Presumably people will not buy permanent storage that does not commit data that is transferred to it? The thing is, the fsync guarantee isn't useless. You "just" have to rewrite any data that you had previously written since the last sync, and be tolerant of partially committed data in the interim.
What if the hardware has its own notion of sync. I am not familiar with disk IO protocols, but I assume they are permitted to store writes in an internal buffer. In such a case, I would expect fsync to issue a sync request to the device and wait until the device reports that the sync is finished. Admittedly, the phrasing of the spec is not 100% clear on this point; but I think the correct reading of it is that the correct behavior is to wait until the device actually commits the data (or at least claims to; at some point broken/lieing hardware is just broken).
Your assumption is correct.