Page MenuHomeFreeBSD

clip the len being copied by copy_file_range() to an exact multiple of hole size
ClosedPublic

Authored by rmacklem on Mon, Sep 28, 1:24 AM.

Details

Summary

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.

Test Plan

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
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; 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).

Fixed the calculation to take *inoffp into account,
as suggested by asomers@.

Use rounddown() as suggested by asomers@.

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.

This revision is now accepted and ready to land.Tue, Sep 29, 3:05 AM