By clipping the len argument of copy_file_range() to an exact
multiple of hole size, holes are more likely to be maintained
during the copy.
A hole can still straddle the boundary at the end of the
copy range, resulting in a block being allocated in the
output file, but this will reduce the likelyhood of this
happening.
Details
Tested using various small copy programs using
copy_file_range(), plus a patched "cp" that does
copy_file_range() with the len argument set to
SSIZE_MAX.
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
What happens if inoffp is not a multiple of the hole size? Shouldn't you try to ensure that len + inoffp is a multiple of the hole size, instead of len?
sys/kern/vfs_vnops.c.sav3 | ||
---|---|---|
3089 ↗ | (On Diff #77582) | This expression is also defined as rounddown(len, blksize). |
sys/kern/vfs_vnops.c.sav3 | ||
---|---|---|
3088 ↗ | (On Diff #77616) | According to pathconf(2), _PC_MIN_HOLE_SIZE has a special meaning for 1. So that's probably a common value. You can optimize this block by changing the test to if (blksize > 1) |
Change the blksize test to handle the special case
where _PC_MIN_HOLE_SIZE is returned as 1.
As well as asomers@ suggested change, I also
changed the blksize code just below it.
I was not aware that the special case of 1 could
be returned.