diff options
author | Luis Henriques <lhenriques@suse.com> | 2019-10-31 14:49:39 +0300 |
---|---|---|
committer | Ilya Dryomov <idryomov@gmail.com> | 2019-11-05 17:42:58 +0300 |
commit | a3a0819388b2bf15e7eafe38ff6aacfc27b12df0 (patch) | |
tree | 16e134b5e219b5d17bfae211d92a16ca269b2e23 /fs/ceph/super.c | |
parent | 5bb5e6ee6f5c557dcd19822eccd7bcced1e1a410 (diff) | |
download | linux-a3a0819388b2bf15e7eafe38ff6aacfc27b12df0.tar.xz |
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: stable@vger.kernel.org
Signed-off-by: Luis Henriques <lhenriques@suse.com>
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Diffstat (limited to 'fs/ceph/super.c')
0 files changed, 0 insertions, 0 deletions