I don't see anything saying that SEEK_HOLE must report every actual hole either.
so an implementation that reported every 0 in the file would be valid
and an implementation that didn't report any holes in the file would be valid (although useless)
I'm arguing that it would be better to allow the flexibility to define what a hole is if applications are going to be modified to make use of this feature.
I'm not sure if the application should define the hole, or if it should be something that's tunable at the system (or device) level. I can definitely see a reluctance to have the app try and figure out what size hole is relevant, but at the same time, the ability to find potential holes without having to push the data all the way to userspace just to find 0's int he file seems like a useful optimisation for a small amount of code.