Issue with ftruncate behavior

Hello,

While conducting tests on file corruption in a UFS partition mounted without the sync flag, I observed some unusual behavior. ftruncate does not appear to respect the sync/async policy through mount and open; it is always executed synchronously. This led to issues when a call to ftruncate was followed quickly by a call to fwrite, and then a kernel panic occurred.
In this case, ftruncate will be committed to the disk while fwrite won't, so that after a reboot, the file may be left empty if ftruncate was called with a length of 0.

I would have expected that if a kernel panic happens, the file would not be modified at all before the syncer commits both ftruncate and fwrite calls to the disk.
I'm aware that even if ftruncate were asynchronously committed to the disk by the syncer thread in the same loop as fwrite, there could still be a window where a panic might leave the file truncated after a reboot, however, that window would be significantly smaller than it currently is, even if kern.filedelay is set to 2.

Is this the expected behavior for ftruncate?

Regards,
Clément.