On Tue, 18 Mar 2025 at 22:17, Trond Myklebust <trondmy@xxxxxxxxxxxxxxx> wrote: > > On Tue, 2025-03-18 at 14:03 -0700, Rick Macklem wrote: > > > > The problem I see is that WRITE_SAME isn't defined in a way where the > > NFSv4 server can only implement zero'ng and fail the rest. > > As such. I am thinking that a new operation for NFSv4.2 that does > > writing > > of zeros might be preferable to trying to (mis)use WROTE_SAME. > > Why wouldn't you just implement DEALLOCATE? > Oh my god. NFSv4.2 DEALLOCATE creates a hole in a sparse file, and does NOT write zeros. "holes" in sparse files (as created by NFSV4.2 DEALLOCATE) represent areas of "no data here". For backwards compatibility these holes do not produce read errors, they just read as 0x00 bytes. But they represent ranges where just no data are stored. Valid data (from allocated data ranges) can be 0x00, but there are NOT holes, they represent VALID DATA. This is an important difference! For example if we have files, one per week, 700TB file size (100TB per day). Each of those files start as a completely unallocated space (one big hole). The data ranges are gradually allocated by writes, and the position of the writes in the files represent the time when they were collected. If no data were collected during that time that space remains unallocated (hole), so we can see whether someone collected data in that timeframe. Do you understand the difference? Lionel
