RE: Issue with ftruncate behavior

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

I understand that async does not guarantee that the order will be preserved. However, I expected that both ftruncate and fwrite calls would be written to disk roughly at the same time just like it would happen for two successive calls to fwrite.
As of now, without the sync flag and with kern.filedelay set to 30, if there is a power failure 20 seconds after the call to both ftruncate and fwrite, on the disk the file will end up truncated without fwrite being processed, which is a bit surprising,
I'd have expected that the file would be left unmodified until the syncer thread processed those dirty buffers

________________________________
De : Konstantin Belousov <kostikbel@gmail.com>
Envoyé : lundi 7 juillet 2025 14:57:19
À : Clément CAZUC
Cc : freebsd-fs@freebsd.org
Objet : Re: Issue with ftruncate behavior

WARNING: This e-mail comes from someone outside your organisation. Do not click on links or open attachments if you do not know the sender and are not sure that the content is safe.

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.