aboutsummaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/netdev-times.py
diff options
context:
space:
mode:
authorLuis Henriques <[email protected]>2019-10-31 11:49:39 +0000
committerIlya Dryomov <[email protected]>2019-11-05 15:42:58 +0100
commita3a0819388b2bf15e7eafe38ff6aacfc27b12df0 (patch)
tree16e134b5e219b5d17bfae211d92a16ca269b2e23 /tools/perf/scripts/python/netdev-times.py
parent5bb5e6ee6f5c557dcd19822eccd7bcced1e1a410 (diff)
ceph: don't allow copy_file_range when stripe_count != 1
copy_file_range tries to use the OSD 'copy-from' operation, which simply performs a full object copy. Unfortunately, the implementation of this system call assumes that stripe_count is always set to 1 and doesn't take into account that the data may be striped across an object set. If the file layout has stripe_count different from 1, then the destination file data will be corrupted. For example: Consider a 8 MiB file with 4 MiB object size, stripe_count of 2 and stripe_size of 2 MiB; the first half of the file will be filled with 'A's and the second half will be filled with 'B's: 0 4M 8M Obj1 Obj2 +------+------+ +----+ +----+ file: | AAAA | BBBB | | AA | | AA | +------+------+ |----| |----| | BB | | BB | +----+ +----+ If we copy_file_range this file into a new file (which needs to have the same file layout!), then it will start by copying the object starting at file offset 0 (Obj1). And then it will copy the object starting at file offset 4M -- which is Obj1 again. Unfortunately, the solution for this is to not allow remote object copies to be performed when the file layout stripe_count is not 1 and simply fallback to the default (VFS) copy_file_range implementation. Cc: [email protected] Signed-off-by: Luis Henriques <[email protected]> Reviewed-by: Jeff Layton <[email protected]> Signed-off-by: Ilya Dryomov <[email protected]>
Diffstat (limited to 'tools/perf/scripts/python/netdev-times.py')
0 files changed, 0 insertions, 0 deletions