> Date: Sun, 07 Jul 2024 14:07:40 -0400 > From: Greg Troxel <[email protected]> > > 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.
