On 09/01/2025 07:54, Christoph Hellwig wrote:
On Tue, Jan 07, 2025 at 05:26:36PM -0800, Darrick J. Wong wrote:
"I think we should wire it up as a new FALLOC_FL_WRITE_ZEROES mode,
document very vigorously that it exists to facilitate pure overwrites
(specifically that it returns EOPNOTSUPP for always-cow files), and not
add more ioctls."
If we added this new fallocate mode to set up written mappings, would it
be enough to write in the programming manuals that applications should
use it to prepare a file for block-untorn writes? Perhaps we should
change the errno code to EMEDIUMTYPE for the mixed mappings case.
Alternately, maybe we/should/ let programs open a lease-fd on a file
range, do their untorn writes through the lease fd, and if another
thread does something to break the lease, then the lease fd returns EIO
until you close it.
This still violates the "no unexpected errors" paradigm. The whole
FALLOC_FL_WRITE_ZEROES (I hate that name btw) model would only work
if we had a software fallback that make the operations slower but
still work in case of an unexpected change to the extent mapping.
Christoph, Do you have any other suggestion on what that software
fallback would look like? I thought that what I had in this series was a
decent approach, i.e. auto-zero unwritten extents, but it seems not.
cheers
