This fixes the case when all the following conditions are true:
1: Incremental OTA
2: When there are sequence of overlapping COPY operations within one merge-window
(510 blocks)
3: Device is rebooted when snapshot-merge is in-progress of this
merge-window. When device reboots, the state of merge-window (of 510 blocks) was
merge-in-progress (aka - only partial set of blocks were merged in
this window thereby the state of the base device is in-complete for
this window)
4: During the next boot, if there any I/O request from the filesystem
which maps to the merge-window in (3):
a: The data has to be retrieved from the scratch space of the
COW until the snapshot-merge for that window is completed.
b: Once the snapshot-merge is complete for that window, data
has to be retrieved from base device.
The bug was in step 4(a) wherein I/O request was getting routed to base
device.
This patch addresses the above flow by fixing step 4(a).
A new vts test has been added to explicitly track this issue.
Additionally, there is no need to re-scan the partition if partition is in merge resume path. This should cut down the overhead of the scan.
Bug: 275296365
Test: 1: 100 iterations of ./vts_snapuserd_test --gtest_filter=SnapuserdTest.Snapshot_COPY_Overlap_Merge_Resume_IO_Validate_TEST
2: Incremental OTA on Pixel 6 Pro with multiple iterations of device
reboot when merge is in progress
Change-Id: Ib53be7f07ff192a84ec7f7049b2c6be01dad1041
Signed-off-by: Akilesh Kailash <akailash@google.com>
cffa413de4