Re: strange zfs size allocation data

[Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>]

> Date: Sun, 07 Jul 2024 14:07:40 -0400
> From: Greg Troxel <gdt%lexort.com@localhost>
> 
> I ran into a test failure with bup, where it was restoring a sparse file
> and trying to validate the resulting disk usage.  It turns out that on
> zfs (NetBSD 10), when you write a file, it shows as using 1 block and
> then some seconds later shows as using the right amount.

zfs's struct stat::st_blocks (i.e., struct vattr::va_bytes/va_blksize,
roughly) gives the number of blocks actually allocated on disk for the
file, plus 1 for some metadata.

Before a newly written file is synced to disk, when it still exists
only in memory, it doesn't have any space allocated on disk for it
(though I expect if you hit the logical reservation limit, you'll see
a write error earlier).

Every 5sec, the system syncs the file system (I forget where this
comes from, whether it's a zfs thing or a NetBSD syncer thing), which
explains why within a couple of seconds you see du(1) output change.

I bet if you fsync just the file you created, or use dd oflag=sync or
oflag=dsync, you will stop seeing the delay.