Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Skip to content
Commit cffa413d authored by Akilesh Kailash's avatar Akilesh Kailash
Browse files

snapuserd: I/O request on overlapping blocks during snapshot-merge.



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: default avatarAkilesh Kailash <akailash@google.com>
parent 7cf712ab
Loading
Loading
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment