Taylor R Campbell <campbell+netbsd-tech-k...@mumble.net> writes: >> Date: Sun, 07 Jul 2024 14:07:40 -0400 >> From: Greg Troxel <g...@lexort.com> >> >> 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.
Ah, this is what I sort of suspected. > 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). This feels like a zfs bug to me. Yes, the blocks are not allocated on disk, but they are essentially reserved and its logically like they are used up. It's a mere artifact of cache coherency that they are not actually allocated on disk. > 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. that's kind of fast vs the old 30s but it explains it. > I bet if you fsync just the file you created, or use dd oflag=sync or > oflag=dsync, you will stop seeing the delay. I see. I wonder if that is wise, or if the test should just wait 10s. The question is making the test fast vs keeping impact low. Given your answer, I'd expect this on any zfs filesystem; this seems not to be a NetBSD thing. I just found this, but it doesn't get into "blocks not allocated yet". https://github.com/openzfs/zfs/discussions/11533
