It's silly that this is being downvoted. Of course POSIX doesn't "require that filesystems not get completely corrupted in the event of a system crash", in the

It's silly that this is being downvoted. Of course POSIX doesn't "require that filesystems not get completely corrupted in the event of a system crash", in the same way that it doesn't require that your RAM isn't faulty or that the computer manages to turn on at all after the next reboot. A software specification and its guarantees only make sense in the context of properly functioning hardware and surrounding software. In this case, that translates to "hardware doesn't randomly lose data" and "file systems do not randomly corrupt themselves", because that is the fundamental job of those systems. fsync() is about durability, telling the POSIX-implementing OS interface to instruct the underlying software (e.g. file system) and hardware to sync the described volatile data into persistent state. For a system running on a ramdisk, that naturally means a no-op; for a network mount it means a roundtrip; for a PC with a hard disk it means that the described data is now on disk, and that it is there, uncorrupted, after an ordinary power failure. If you have broken RAM, a disk that lies about flush commands, or synced only a part of the intended data (forgotten to fsync the dir), then the POSIX system has still done its job regarding durability, and fulfilled its guarantees.