On Mon, Jun 09, 2025 at 09:33:37PM -0700, Christoph Hellwig wrote: > On Thu, Jun 05, 2025 at 01:33:57PM -0400, Brian Foster wrote: > > iomap_zero_range() has to cover various corner cases that are > > difficult to test on production kernels because it is used in fairly > > limited use cases. For example, it is currently only used by XFS and > > mostly only in partial block zeroing cases. > > > > While it's possible to test most of these functional cases, we can > > provide more robust test coverage by co-opting fallocate zero range > > to invoke zeroing of the entire range instead of the more efficient > > block punch/allocate sequence. Add an errortag to occasionally > > invoke forced zeroing. > > I like this, having an easy way to improve code coverage using the > existing fallocate and errtag interfaces is always a good thing. > > Can I assume you plan to add a testcase using the errtag to xfstests? > Well that is kind of the question.. ;) My preference was to either add something to fstests to enable select errortags by default on every mount (or do the same in-kernel via XFS_DEBUG[_ERRTAGS] or some such) over just creating a one-off test that runs fsx or whatever with this error tag turned on. [1]. That said, I wouldn't be opposed to just doing both if folks prefer that. It just bugs me to add yet another test that only runs a specific fsx test when we get much more coverage by running the full suite of tests. IOW, whenever somebody is testing a kernel that would actually run a custom test (XFS_DEBUG plus specific errortag support), we could in theory be running the whole suite with the same errortag turned on (albeit perhaps at a lesser frequency than a custom test would use). So from that perspective I'm not sure it makes a whole lot of sense to do both. So any thoughts from anyone on a custom test vs. enabling errortag defaults (via fstests or kernel) vs. some combination of both? Brian [1] Eric also raised the idea of branching off "test tag" variants of errortags that might help distinguish injection points that control behavior vs. those that truly create errors. That could reduce confusion for testers and whatnot. I haven't dug into viability, but in theory that could also define a set of events that don't spew event trigger noise into dmesg if certain events were to be enabled by default (again, on debug kernels only).
