That's great Hannes. Hopefully they'll be able to figure out the behavior causing the issue from the default of "zfs_bclone_wait_dirty=0".
I remember at the time thinking zfs always has data integrity as it's number one objective so I couldn't understand why the default wouldn't be 1 as every write or clone operation should always reliably succeed regardless of the IO pattern being generated by the application.
zfs_bclone_wait_dirty=0|1 (int)
When set to 1 the FICLONE and FICLONERANGE ioctls wait for dirty data to be written to disk. This allows the clone operation to reliably succeed when a file is modified and then immediately cloned. For small files this may be slower than making a copy of the file. Therefore, this setting defaults to 0 which causes a clone operation to immediately fail when encountering a dirty block.
I remember at the time thinking zfs always has data integrity as it's number one objective so I couldn't understand why the default wouldn't be 1 as every write or clone operation should always reliably succeed regardless of the IO pattern being generated by the application.
zfs_bclone_wait_dirty=0|1 (int)
When set to 1 the FICLONE and FICLONERANGE ioctls wait for dirty data to be written to disk. This allows the clone operation to reliably succeed when a file is modified and then immediately cloned. For small files this may be slower than making a copy of the file. Therefore, this setting defaults to 0 which causes a clone operation to immediately fail when encountering a dirty block.
Statistics: Posted by ashleyw — May 12, 2025 10:43 am
