We want to print how much total data we are attempting to write if a
failure occurs
Bug: 336461151
Test: th
Change-Id: I269b7e280df34994c80fa8ef7d39163d053fa9ea
This adds a raw partition to /data.
Bug: 336319772
Change-Id: Iaae51452be621a15ccd9c2530dae44f4c8714b2f
Signed-off-by: Jaegeuk Kim <jaegeuk@google.com>
Remove hard coded global variables referencing cow version in
libsnapshot. This value should stem from the build system, or set
individually in test cases.
Bug: 307452468
Test: th
Change-Id: I3d536246008acca92cd93e77886e5f7d17a131e0
If the COW device is allocated only from /data, then
the COW device name will end with -cow-img. Hence, check
that path as well.
Bug: 335552315
Test: snapshotctl apply-update
Change-Id: Id3c5cf8afd77994da117de41bb98a226b350f8e4
Signed-off-by: Akilesh Kailash <akailash@google.com>
Zstd compression goes all the way down to -7. zstd compression level -3
gives around the same compression ratio as lz4 level=3. Need further
testing to see performance comparison
Test: ota_from_target_files, update_device.py
Change-Id: Ic082b31aa8af938f80be628c73667e02353835f0
thin-pool and thin targets are supported via DmTargetThinPool and
DmTargetThin. DM_TARGET_MSG is also added via a new method
SendMessage() because it's used to create a thin volumn.
dmctl is extended to support thin-pool and thin targets.
TODO: thin-pool target constructor can accept feature arguments.
Bug: 327081431
Test: atest libdm_test (CF with dm-thin enabled kernel)
Change-Id: I4c51c668bfe1489b959f6d03c205a5e2e63d9a1d
If partitions are mounted off the daemon, there is no need
to kill if the tests are being run for legacy vab snapshots.
This also removes vabc_legacy_test as it is no longer required.
Bug: 331053511
Test: vab_legacy_test, vts_libsnapshot_test on Pixel - No flake observed
with 10 iterations
Change-Id: Ie8b29fef77948d23d920c19d816376290cf2fed9
Signed-off-by: Akilesh Kailash <akailash@google.com>
If on Androd 12, continue to use snapshots
Bug: 304829384
Test: OTA on Pixel
Change-Id: I94890c308e7f297b695ddbd71659ebb1cf4d278c
Signed-off-by: Akilesh Kailash <akailash@google.com>
ro.virtual_ab.userspace.snapshots.enabled is a vendor property which isn't present in Android S. Hence, during OTA install with S vendor, userspace_snapshots is disabled.
However, both update_engine and snapuserd are already on the system partition during install. Hence, forcefully enable userspace_snapshots if this is a path of legacy dm-snapshots with Vendor on Android S.
Bug: 331156940
Test: OTA tests on treehugger, pixel OTA
Change-Id: I3d1c03493d83e670e37df088d4b676c4aa1dc720
Signed-off-by: Akilesh Kailash <akailash@google.com>
Change the meaning of batch_size_. Previously, a batch size of 200 meant
200 compressed data ops. With variable block size, each compressed data
op can be up to 256k uncompressed size -> batch size meaning should be
changed to 200 blocks of block size.
With this being said, the default batch size can be increased to 4mb to
better accomodate variable block size
The way we calculate the number of blocks to compress at once also
needs to be changed. Since there's no way of determining the comperssed
data size ahead of time, allow overwriting the cache by batch_size_ and
then flushing the cache as needed
Bug: 322279333
Test: Ota on pixel and measuring system image cow
Change-Id: Ie8e08d109dc5c3b4f5f36a740bbbcd37362a7ab3
With the modified cache system we might be processing big replace ops at
once. Our old tests didn't catch a case where a big replace op was
chunked into seperate batch writes.
Test: cow_api_test
Change-Id: I3bc80a2f9ed3e4c73dd9f74d9affaba79d49e4d2
Currently if our iov that we are trying to write is greater than 1024
our write will fail with error "INVALID ARGUMENT". This is because
pwritev() system call takes a max input size of IOV_MAX (which is device
dependant).
With our increased cache size of 1mb or maybe even more (or if user
configures batch size to be large), our write size could be greater than
IOV_MAX, and will fail with an unhelpful error. We should chunk these
writes to ensure they succeed.
Bug: 322279333
Test: cow_api_test + manual testing with large iov write sizes
Change-Id: Ia1fb53cbfc743cfcdfc7256ff9df075ad0c2dd38
Cow Writer used to fail with ENOSPC during initialization.
Try temporaryFile creation with path set to current working directory.
Bug: 328879200
Test: th, snapuserd_test
Change-Id: I7b3833967952c74142f1d5a35cb8d94dd6d894fc
Signed-off-by: Akilesh Kailash <akailash@google.com>
Clean up all the legacy dm-snapshot based approach.
This will continue to maintain backward compatibility with vendor
partition on Android S.
Bug: 304829384
Test: OTA on Pixel
th - OTA from Android S to TOT with vendor on S
Change-Id: Id9263be881dd1a06923cd0ace007f1c027e6969d
Signed-off-by: Akilesh Kailash <akailash@google.com>
During OTA install, when vendor partition is on Android S, add a new flag in SnapshotUpdateStatus file to indicate that we need to support dm-snapshot based snapshot process. This will be used only during post OTA reboot.
The primary change here is the OTA install path. Earlier, dm-snapshot based approach was used; with this change, since both "snapuserd" and "update-engine" resides on system partition, OTA installation will use the userspace snapshot approach.
To maintain backward compatibility, the new flag "legacy_snapuserd" is used only after OTA reboot. This flag will make sure that update-engine will take the dm-snapshot based approach post reboot and for the entire duration of snapshot-merge.
Additionally, during first-stage init if the vendor is on Android S, then "snapuserd" binary will continue to work based off dm-snapshot as none of this change will impact the mount process.
Bug: 304829384
Test: OTA on Pixel
th - OTA from Android S to TOT with vendor on S
Change-Id: Idd9a60b09417cee141b2810e2d4b35e91c845a5c
Signed-off-by: Akilesh Kailash <akailash@google.com>
Updated FuzzedDataProvider value ranges to avoid Abort due to division by zero.
exec/s: 14786
Test: ./liblp_builder_fuzzer clusterfuzz-testcase-minimized-liblp_builder_fuzzer-5371251289292800
Bug: 328948968
Change-Id: I2568bd104b5fb09744baf42ffca6aabd24797b12
We have updated logic for v3 cow we should allow non-data ops to be
cached at 16x the amount of data ops. Changing the reserve size to match
this.
Test: th
Change-Id: I825ffef4e1a2ce4eb5c105d266bf95cb3d776ed9
This adds an option "ima" in dmctl.
$ dmctl ima product-verity
Targets in the device-mapper table for product-verity:
0-7463768: verity, target_name=verity,target_version=1.9.0,hash_failed=V,verity_version=1,data_device_name=254:4,hash_device_name=254:4,verity_algorithm=sha256,root_digest=d7af9fcb04d184219ba5477b97bb2bbc89fd23a46e03d1dea31d674cc4934769,salt=19d4f2345adfc8b7cc22a3c2f21dd413e5020fc7920a08a33f46f3c61492dfcc,ignore_zero_blocks=y,check_at_most_once=n,verity_mode=restart_on_corruption;
Change-Id: I057970b6c786b3f9a394b4919f5f5115b27cbc08
Signed-off-by: Jaegeuk Kim <jaegeuk@google.com>
Remove temporary estimation solution (using 4k to overestimate the cow).
With the updated estimation logic, we should be able to accurately
estimate the cow size with variable block sized compression
Bug: 322279333
Test: th
Change-Id: I199970048605a8d21d3791614ad88ca61662e1a3
Since http://r.android.com/2994274, snapshotctl can be run by init.
Therefore, we need it to log to logd for better debuggability.
Bug: 311377497
Test: adb shell setprop sys.snapshotctl.map requested
Test: adb shell setprop sys.snapshotctl.unmap requested
Change-Id: I287ecf77d45fb9e6c44bea36e14d2624029afea5
This helps reviewers understand which VTS requirement these test are
covering
Bug: 302208814
Test: th
Change-Id: I52712d9888b73fc7a9f8eeeb035a3303618efd69
This reverts commit 1af7260931.
Fix: Allow BootControlClient.h to be used in -user builds
Bug: 319309466
Test: Build on -user branch
Change-Id: I93e95e35b29a98816b2f33fe9fa6859655934cd5
$snapshotctl apply-update <directory containing snapshot patches>
This command is equivalent to applying incremental-ota but
bypasses all of the update-engine subsystem. Snapshot-patches
which are created on the host will be used directly and
will be written to the COW block devices.
No change to any of the libsnapshot or the I/O path logic.
Once the snapshot patches are applied, device is ready
to reboot as if an OTA update is applied.
Once the device reboots, snapshot merge will be initiated
as usual.
This will help test the changes to libsnapshot + init + snapuserd
extremely quick.
Incremental flashing becomes quite simple in the CI workflow.
Here are numbers tested on live builds where the actual builds/testing
is done on CI.
Patch-Create+Apply = Create the snapshot patches between two
builds and apply them to the device
Branch(main) Patch-Creation+Apply Merge Snapshot-size
=================================================================
Build-1 -> Build-2 14 seconds 40 seconds 160MB
Build-2 -> Build-3 21 seconds 26 seconds 331MB
Build-3 -> Build-4 30 seconds 45 seconds 375MB
Build-X -> Build-X 3 seconds 4 seconds 8MB
Bug: 319309466
Test: On Pixel 6, incremental builds
Change-Id: I271b2cb5df4abde91571ec70ce06f926a1d01694
Signed-off-by: Akilesh Kailash <akailash@google.com>
Now that V3 is enabled, relax the header version check.
For V3, header op_count_max contains the information of the device size.
Bug: 299011882
Test: snapshotctl map-snapshots on Pixel with V3 format
Change-Id: Ia1cb20b24857136a742e20408ee95e56e98b256a
Signed-off-by: Akilesh Kailash <akailash@google.com>
Alternate dispatching blocks between threads rather than splitting the
data beforehand and then sending to threads in order to ensure that
single threading + multithreading chunks data at the same locations.
Without this change, the resulting op count + data section of the cow
will differ between --enable-threading && --disable-threading at
runtime, which is a result we don't want
Test: th
Change-Id: I3ed8add0552745a281fce2aa7f1d1d32eb547e63
Add dm stripe in dmctl framework to support stripe on two block devices.
Bug: 321628121
Change-Id: I2f326f19f7ccff1ee03598743022fb702b3e8d6a
Signed-off-by: Ed Tsai <ed.tsai@mediatek.com>
