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
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
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Skipped - Unit
Tests Skipped - Build Status
Buildable 33866
Event Timeline
Comment Actions
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 | This expression is also defined as rounddown(len, blksize). | |
| sys/kern/vfs_vnops.c.sav3 | ||
|---|---|---|
| 3088 | 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) | |
Comment Actions
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.