Re: Issue with ftruncate behavior

On Mon, Jul 07, 2025 at 09:36:26AM +0000, Clément CAZUC wrote:
> 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?

Yes, it is.
Why do you think that async would care to preserve the order?  It is async.