On Thu, Nov 21, 2024 at 07:28:09AM -0500, Brian Foster wrote: > IIRC it was to accommodate the test program, which presumably used > discard for efficiency reasons because it did a lot of context switching > to different point-in-time variations of the fs. If the discard didn't > actually zero the range (depending on the underlying test dev), then at > least on XFS, we'd see odd recovery issues and whatnot from the fs going > forward/back in time. But the fundamental problem is that discard does not actually zero data. It sometimes might, but also often doesn't because it's not part of the contract. That's why my patch two switch to the zeroing ioctl is the right thing. Note that this doesn't mean explicitly writing zeroes, it still uses zeroing offloads available in the drivers. > I don't recall all the specifics, but I thought part of the reason for > using discard over explicit zeroing was the latter made the test > impractically slow. I could be misremembering, but if you want to change > it I'd suggest to at least verify runtimes on some of the preexisting > logwrites tests as well. I'm all for speeding up tests. But relying on a unspecified side effect of an operation and then requiring a driver that implements that side effect without documenting that isn't really good practice.
