diff options
author | Ashish Samant <[email protected]> | 2016-09-19 14:44:42 -0700 |
---|---|---|
committer | Linus Torvalds <[email protected]> | 2016-09-19 15:36:17 -0700 |
commit | d21c353d5e99c56cdd5b5c1183ffbcaf23b8b960 (patch) | |
tree | d0c56ebf05ea58999b3e1ec2fae968e7ee94c05b /lib/mpi/mpiutil.c | |
parent | d979a39d7242e0601bf9b60e89628fb8ac577179 (diff) |
ocfs2: fix start offset to ocfs2_zero_range_for_truncate()
If we punch a hole on a reflink such that following conditions are met:
1. start offset is on a cluster boundary
2. end offset is not on a cluster boundary
3. (end offset is somewhere in another extent) or
(hole range > MAX_CONTIG_BYTES(1MB)),
we dont COW the first cluster starting at the start offset. But in this
case, we were wrongly passing this cluster to
ocfs2_zero_range_for_truncate() to zero out. This will modify the
cluster in place and zero it in the source too.
Fix this by skipping this cluster in such a scenario.
To reproduce:
1. Create a random file of say 10 MB
xfs_io -c 'pwrite -b 4k 0 10M' -f 10MBfile
2. Reflink it
reflink -f 10MBfile reflnktest
3. Punch a hole at starting at cluster boundary with range greater that
1MB. You can also use a range that will put the end offset in another
extent.
fallocate -p -o 0 -l 1048615 reflnktest
4. sync
5. Check the first cluster in the source file. (It will be zeroed out).
dd if=10MBfile iflag=direct bs=<cluster size> count=1 | hexdump -C
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ashish Samant <[email protected]>
Reported-by: Saar Maoz <[email protected]>
Reviewed-by: Srinivas Eeda <[email protected]>
Cc: Mark Fasheh <[email protected]>
Cc: Joel Becker <[email protected]>
Cc: Junxiao Bi <[email protected]>
Cc: Joseph Qi <[email protected]>
Cc: Eric Ren <[email protected]>
Cc: <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Diffstat (limited to 'lib/mpi/mpiutil.c')
0 files changed, 0 insertions, 0 deletions