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>
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
Log the compression algorithm and compression factor used during OTA for easier debugging
Test: th
Change-Id: Ic50989d7e233983d6299163fc647eb739a0b7cb2
Since variable block compresses blocks and there is no longer a 1:1
mapping between ops to blocks, we need to update this check in
EmitBlocks to the actual number of compressed blocks written.
Since single threaded + multi threaded + no compression invoke different
code paths. Ensure that that blocks written are still equivalent to
blocks.size(). Adding two test cases to cover these situations.
Test: th
Change-Id: If81eccf74333292a114268862dde0fe49681ef35
1: Move to v3 COW writer
2: Enable variable block size. Default compression set to lz4
with compression factor 64KiB
3: Prepare merge sequence so that device can initiate the merge
4: Verify the merge order
Bug: 319309466
Test: On Pixel 6
This was 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 Snapshot-size
=============================================================
Build-1 -> Build-2 14 seconds 160MB
Build-2 -> Build-3 21 seconds 331MB
Build-3 -> Build-4 30 seconds 375MB
Build X -> Build X 3 seconds 8MB
Change-Id: I96437032de029d89de62ba11fe37d9287b0a4071
Signed-off-by: Akilesh Kailash <akailash@google.com>
In newer versions of libc++, std::char_traits<T> is no longer defined
for non-character types, and a result, std::basic_string<T> and
std::basic_string_view<T> are also no longer defined for non-character
types. See
https://discourse.llvm.org/t/deprecating-std-string-t-for-non-character-t/66779.
Replace them with std::vector<T> and std::span<const T>.
Bug: 175635923
Test: m MODULES-IN-system-core-fs_mgr
Test: /data/nativetest64/cow_api_test/cow_api_test
Change-Id: Ife2e87833ced43ff24e5765998cb6993e4f9b4c0
The flow of I/O path is as follows:
1: When there is a I/O request for a given sector, we first
check the in-memory COW operation mapping for that sector.
2: If the mapping of sector to COW operation is found, then the
existing I/O path will work seamlessly. Even if the COW operation
encodes multiple blocks, we will discard the remaining data.
3: If the mapping of sector to COW operation is not found:
a: Find the previous COW operation as the vector has sorted sectors.
b: If the previous COW operation is a REPLACE op:
i: Check if the current sector is encoded in the previous COW
operations compressed block.
ii: If the sector falls within the range of compressed blocks,
retrieve the block offset.
iii: De-compress the COW operation based on the compression
factor.
iv: memcpy the data based on the block offset.
v: cache the COW operation pointer as subsequent I/O requests
are sequential and can just be a memcpy at the correct offset.
c: If the previous COW operation is not a REPLACE op or if the
requested sector does not fall within the compression factor
of the previous COW operation, then fallback and read the data
from base device.
Snapshot-merge:
During merge of REPLACE ops, read the entire op in one shot, de-compress
multiple blocks and write all the blocks in one shot.
Performance:
go/variable-block-vabc-perf covers detail performance runs
on Pixel 6 for full and incremental OTA.
Bug: 319309466
Test: snapuserd_test covers all the I/O path with various block sizes.
About 252 cases with all combinations and tunables.
[==========] 252 tests from 4 test suites ran. (702565 ms total)
[ PASSED ] 252 tests.
On Pixel 6:
=======================================
COW Writer V3:
for i in full, incremental OTA
for j in 4k, 16k, 32k, 64k, 128, 256k
for k in lz4, zstd, gz
install OTA, reboot, verify merge
=======================================
COW Writer V2:
for i in full, incremental OTA
for j in 4k
for k in lz4, zstd, gz
install OTA, reboot, verity merge
=====================================
Change-Id: I4c3b5c3efa0d09677568b4396cc53db0e74e7c99
Signed-off-by: Akilesh Kailash <akailash@google.com>
This patch supports compression for bigger block size.
3 bits [57-59] in the COW Operation "source_info_" field is used to store
the compression factor. Supported compression factors are power of 2
viz: 4k, 8k, 16k, 32k, 64k, 128k, 256k.
Only REPLACE operations will have the bigger block size support for now.
This can be extended to other operations later.
The write path in EmitBlocks() has the core logic wherein consecutive
sequence of REPLACE ops are compressed based on the compression factor
settings. Thus, for a 64k compression factor, there will be just one
COW operation which encodes all the 16 operation and the entire 64k
block is compressed in one shot.
NOTE: There is no read I/O path support in this patch. Subsequent patch
will have the read support.
Performance data (with read I/O path support in subsequent patch):
go/variable-block-vabc-perf covers detail performance runs
on Pixel 6 for full and incremental OTA.
TL;DR:
Performance of a full OTA (All numbers are compared against 4k block
size)
=======================================
Snapshot-size:
~10-11% decrease in snapshot-size (disk-space) for zstd with 256k block
size.
~8% decrease in snapshot-size (disk-space) for lz4
Install time:
~13% decrease in OTA install time for zstd with 256k block size.
Snapshot-merge:
~50% decrease in snapshot-merge time with 256k block size for zstd
Post OTA boot-time:
~10.5 decrease in boot time for 64k block size for zstd
In-memory footprint for COW operations:
~80% decrease in memory footprint for 256k block size. (58MB -> 9.2MB)
============================================
For more improvements, further tuning of zstd/lz4 is
required primariy the compression levels, zstd compression window,
performance of gz with compression levels.
Bug: 319309466
Test: cow_api test covering all the supported block sizes for v3 writer.
On Pixel 6:
=======================================
COW Writer V3:
for OTA in full, incremental OTA
for block_size in 4k, 16k, 32k, 64k, 128k, 256k
for compression_algo in lz4, zstd, gz, none
install OTA, reboot, verify merge
=======================================
COW Writer V2:
for OTA in full, incremental OTA
for block_size in 4k
for compression_algo in lz4, zstd, gz, none
install OTA, reboot, verity merge
=====================================
Change-Id: I96201f1609582aa9d44d8085852e284b0c4a426d
Signed-off-by: Akilesh Kailash <akailash@google.com>
Intermediate CL needed before variable block size can land. Since v3 is
enabled on cuttlefish, the base build needs to write the
compression_factor in order for reader to properly parse. Otherwise
we'll fail OTA test
Test: th
Change-Id: Ia353aae8e668858851073f09308909ae70d7854e
In the case that op_count_max is read in as zero, we should use the
upper bound of max blocks as the estimation. One case in which this
error can happen is if a v2 cow estimator is used, we should still be
able to run an OTA if we upper bound our ops buffer size estimation.
Test: th
Change-Id: I97ca66368d6631bf43c8911ed66f99c9e8096e2d
Parse manifest compression_factor and set CowOptions appropriately. This
allows v3 writer to use compression factor in OTA. Updating some
comments about supported compression algorithms
Test: th
Change-Id: I88f254087e536d9e5925064f85317f0acce280ee
With variable block size compression being added, the number of ops
written cannot be calculated directly as easily since one op can cover
the data for multiple ops previously. We can get rid of this check for
XOR and Raw blocks as
within WriteOperation() we already make a check to see if we are
exceeding op_count_max limit.
We still need to keep this check for EmitZeroBlocks and EmitCopyBlocks
since the number of operations is determined ahead of time in those
function calls. Without this check in place, the ops will be added to
cached ops and return true when ops cannot be written.
with this change, v3 cow ota now works on cuttlefish with support for
variable block size compression.
Test: th
Change-Id: Ia55f152f5deb67a9022d0feff112345e72741dd3
Changes to structure of v3 header + operation needed for variable block
size. Seperating this CL from the variable block size one so we can get
v3 enabled on cuttlefish
the op count type changes are so that op count matches the type of
max_blocks. Max_blocks is used when op buffer size is not set -> we
default to upper bound of one operation per block in the partition.
Test: th
Bug: 307452468
Change-Id: I1a2581763a4fd6be5d5795f7e4781023e9984256
Assign CPUSET_SP_BACKGROUND taskprofile to snapshot merge threads.
This will ensure that the threads will not run on big cores.
Additionally, reduce the flushing of data to 1MB after merging REPLACE ops.
No major regression observed on snashot merge time.
On Pixel 6 for incremental OTA of 500M, snapshot merge time increased
from 72 seconds to 76 seconds after this patch.
Bug: 311233916
Test: Full and incremental OTA on Pixel 6 - Verify merge threads not on big cores
Change-Id: I455afdac0b77227869d846d0c4472ea9eb34c41c
Signed-off-by: Akilesh Kailash <akailash@google.com>
Performance of COW v3 is now on par with v2 in both multi-threaded and
single threaded configurations. Note, v2 cow writer can cache up to 1024
blocks in memory if multi-threaded compression is enabled(even though
batch size is configured as 200). For a fair comparison, benchmarks are
ran with batch size of 256. For batch size of 256 or greater, v2 and v3
have similar multi-threaded performance.
Test: th
Bug: 313962438
Change-Id: I377c8291689a7a038bb00b09d7371a155e6972e9
Adding a check here to ensure that next_data_pos_ isn't modified since
initialization. After sizing the sequence buffer, this value should be
the initialized value + the size of sequence buffer.
Test: cow_api_test
Change-Id: I9c79041b72544500989860a13ca6c25830d28750
Update snapshot.cpp to grab estimate_op_buffer_size &
estimate_sequence_buffer_size from update_engine. Update v3 writer to
use these options to size the buffers appropriately.
we probably don't need the fields for merge metrics yet but will leave
it here for now
Test: th
Bug: 313962438
Change-Id: I08252ff66174de9bafaf8dbe9115d9d049084c4c
Adding a cow size info struct as writer will now need to know the op buffer
size at the time of initialization. The sequence of events is as follows
(same as estimate_cow_size but putting down here for clarity)
1. ota_from_target_files does dry run to determine cow size + ops buffer
size
2. data is passed through delta archive manifest
3. snapshot.cpp parses these fields and confgiures cowoptions struct to
pass to writer initialization
4. cow is initialized with correct sizing. Data is incrementally added
at the ends of the cow ops buffer (which is why we need to know the
sizing ahead of time)
Test: ota
Change-Id: I950e5ef82c9bd7e9bd9603b0599c930767ee3f0d
Performance of V3 COW writer is now on-par with V2 in both incremental
OTA and full OTA.
Test: th
Bug: 313962438
Change-Id: If56e0fe42367f947c513fc4c93119c3825763cb9
If the daemon is alive, detach it before explicitly terminating service.
Bug: 316876960
Test: treehugger presubmit tests
Change-Id: I94d9d1a0dab09a6b016f422c7497098abc86add8
Signed-off-by: Akilesh Kailash <akailash@google.com>
If sequence data is written and the number of ops reaches the maximum,
op data will corrupt the block data because location of block data is
stale after writing sequence data. Fix by resetting location of block
data after EmitSequenceData()
Test: th
Bug: 313962438
Change-Id: Ib53b81772ba341cdf5c240baaee7c10725a365c3
There is no need to connect to daemon for legacy VAB.
Bug: 311900089
Test: treehugger - presubmit
Change-Id: I2256cee611431ab2a286730c61092d2c546caf1e
Signed-off-by: Akilesh Kailash <akailash@google.com>
During PrepareSnapshotPartitionsForUpdate, we attempt to connect to
snapuserd with a 5s timeout, only to tell snapuserd to shutdown
immediately. If snapuserd isn't running, we will wait-out the whole 5
seconds. Change the logic to return early if socket_connect() calls
return ENOENT, indicating that snapuserd socket isn't used by any
process. This reduces allocateSpaceForPayload() time from 6s to 1s.
Test: th
Bug: 315215541
Change-Id: Ib24d7c63733a896c082ac92aaa88ad52d050a2a5
This reverts commit 9d0c06d3e2.
The failure is fixed by https://r.android.com/2725997. Workaround no
longer needed.
Test: manual
Bug: 208565717
Bug: 295944813
Change-Id: I83638938bf52a4b2b1e72743f892c579622ba9e6
This also improves atomicity of ops. If a single Add*Blocks() call
with 100 blocks failed in the middle, partially written blocks would be
discarded, and op count on disk stays unchanged. Previously wew ould
update the op count on disk with partially written blocks, causing
labels to be inaccurate.
Test: th
Bug: 313962438
Change-Id: If175a705f6ec46c1b25c52d0d9f02f01a540ce55
Current cow size estimation is computed by taking the offset of next
data write. However, during COW size estimation we repeatdly increment
op_count_max. Since data section is placed right after op section,
incrementing op_count_max has the effect of moving the beginning of
data section. next_data_pos_ is never updated in this process, causing
the final estiamte to be off.
Test: th
Bug: 313962438
Change-Id: I250dff54c470c9c20d6db33d91bac898358dee31
Since currently implementation just does an bitwise or with the
storage unit, multiple calls to set_source would result in overlapping
bits. Fix by first clear the existing storage.
Test: th
Bug: 313962438
Change-Id: Iecfe8dd244c0f65ecd3cacb0404fdc39ef836d97
Allow O_DIRECT reads on source block device.
This will further cut down the Active and Inactive file pages
during partition verification.
On Pixel 6 after incremental OTA - Post OTA reboot:
Without patch With patch Delta
--------------------------------------------------------
Inactive(File): 4992MB 3887MB ~22%
Active(File): 1465MB 1014MB ~30%
Boot time however increases from 25 to 30 seconds.
This is not yet enabled. This will be behind a sysprop flag
or for low memory devices and will be enabled later.
Additionally, set the priority of worker threads to normal.
Merge threads priority is reduced. This will help low memory
devices as tested on Pixel watch.
Bug: 311233916
Test: OTA on Pixel 6
Change-Id: Icacdef08d68e28d3062611477703e7cf393a9f10
Signed-off-by: Akilesh Kailash <akailash@google.com>
Scanning of partitions post OTA leads to memory pressure. Tune
the read-ahead of source and COW block device. This is currently
set to 32KB.
This reduces Inactive(file) and Active(file) usage during entire
duration of boot post OTA.
On Pixel 6: For incremental OTA ~400M. During boot:
Without-patch With-patch Delta
--------------------------------------------
1: Peak Inactive(file): 4469MB 3118MB ~30%
2: Peak Active(file): 985MB 712MB ~27%
No regression observed on boot time.
Additionally, cut down the number of threads to verify the partitions.
Bug: 311233916
Test: Incremental OTA on Pixel 6
Change-Id: I0b842776c36fa089c39c170fa7bf0f246e16636d
Signed-off-by: Akilesh Kailash <akailash@google.com>
This does not change the default cow version. Currently v2 is still the
default. This CL only enables OEMs to set virtual_ab_cow_version to 3
for testing purposes.
Test: th
Bug: 313962438
Change-Id: I7a328fa32283560a48604ffe02edd2551ac49a83
We can shove type into source info to save 8 bits in per cow operation.
We only need 4 bits inside of source_info to enumerate all the types of
Cow Operation. Since CowOperationV3 is not used on disk(just yet) , we
can make format changes.
This CL is mechanical:
1. Remove tye .type field from CowOperation struct
2. Add a type() getter method to CowOperation struct
3. Replace all existing usage of `type` member with the new getter
No functional changes, just refactorings.
Test: th
Bug: 304602386
Bug: 313962438
Change-Id: I85d89c71fc6afede12ea299a4a3e3b2184ea2d8b
