For symmetry, add function CleanupOldScratchFiles in conditional compilation blocks which missing it.
Test: monkey test for one day and one night
Signed-off-by: Jintao Zhu <zhujtcsieee@gmail.com>
Change-Id: Ie754427334c9a9bb7cfed70df45f439c60c9ab16
As ReadFstabFromFile() may append / remove / modify the fstab read from
the file, we cannot make assumptions about the number of fstab entries.
We can however test that the returned fstab contains at least the
entries we expect.
Fixes: 185826755
Test: atest CtsFsMgrTestCases on GSI & DSU
Change-Id: I539e7eed3f7ae14db7e9983bed7f68754c9fff39
The parameters "--debug-cache" and path are close to each other, eg:
01-09 17:14:52.058 648 648 I vold : [libfs_mgr]Running
/system/bin/fsck.f2fs -a -c 10000 --debug-cache/dev/block/dm-10
Add a space between them to separate.
Signed-off-by: jiahao <jiahao@xiaomi.com>
Change-Id: Ie2929b541d5907a521c7b97aaed31fdca381fc1a
When appending, if the cluster should end after the given label, ensure
that it does.
Bug: 183985866
Test: cow_api_test#ResumeEndCluster
Change-Id: Ie93d09b3431755d0b9b92761619d55df7f9f6151
When opening in append mode, we could write less than what was present
before. This could result in data blocks referencing beyond the end of
the file, or partially written ops. Zeroing these out will prevent
invalid leftovers from potentially causing confusion.
Bug: 183985866
Test: cow_api_test
Change-Id: I56f0218f3ea5b83c0614d1b86e81a4ca885f5c5e
When opening in append mode, we ftruncate() the COW. This has three side
effects:
(1) If the COW is never modified, or Finalized(), the state of the COW
will have changed. Ideally it should only change on an explicit
write operation.
(2) Data after the current cluster will be accidentally thrown away.
(3) The ending "cluster" op will be thrown away if the current cluster
was incomplete, and thus the last valid label could be invalidated.
Bug: 183985866
Test: cow_api_test
Change-Id: I3c9a38553b7492a3d6e71d177d75ddb1b6490dfe
This patch adds an option, readahead_size_kb in fstab entry option. It supports
to set a proper readahead_size per block/dm devices before using them by mount,
which is useful for low/high-end devices when addressing memory pressure issue.
Bug: 181567573
Signed-off-by: Jaegeuk Kim <jaegeuk@google.com>
Change-Id: I549962e68f8488417d76bcfb283958bc33fd5d7a
Example log line:
update_engine: Block device was lazily unmounted and is still in-use:
/dev/block/dm-28; possibly open file descriptor or attached loop device.
This will help diagnose bugs such as b/184715543 in the future.
Bug: N/A
Test: manual test
Change-Id: Ia6b17fe9bd1796d59be7fc0b355218509acfd4af
When all threads are terminated, dm-user handler's are removed
from the list. When the last handler is removed, daemon is
shutdown gracefully.
Bug: 183652708
Test: 1: Apply full OTA and verify daemon is terminated; reapply the OTA
to verify daemon is restarted again.
2: vts_libsnapshot_test
Signed-off-by: Akilesh Kailash <akailash@google.com>
Change-Id: Ibd41223fc0eba884993a533fcc95661f72805db2
ReadFstabFromFile() calls access() to check the existence of DSU
metadata files to determine if device is in DSU running state. This is
error prone because a failed access() can mean non-exsitent file as well
as the caller lacking the permission to path resolute the pathname.
Strengthen ReadFstabFromFile() to check the errno after a failed
access() or open(), if the errno is not ENOENT, then return with error,
as this may be indicating the caller doesn't have sufficient access
rights to call ReadFstabFromFile().
After this change, processes would need these policies to call
ReadFstabFromFile():
allow scontext { metadata_file gsi_metadata_file_type }:dir search;
And these policies to call ReadFstabFromFile() within a DSU system:
allow scontext gsi_public_metadata_file:file r_file_perms;
Bug: 181110285
Test: Presubmit
Change-Id: I1a6a796cb9b7b49af3aa5e7a5e8d99cde25e5857
Minor refactoring and renaming, goal is to make the follow-up patch
easier to read.
Bug: 184132970
Test: Presubmit
Change-Id: I66416161b30ac310934d901cbaf11bc926e2cbf7
When worker threads were created, snapuserd was converted to a
shared_pointer. Earlier, memory was forcefully released
by setting snapuserd to nullptr which worked as it
was a unique pointer. Now, every worker thread holds
a reference. Clear the vector once all the worker
threads are terminated.
Test: Apply OTA and verify memory is released after OTA is applied
Bug: 183652708
Signed-off-by: Akilesh Kailash <akailash@google.com>
Change-Id: I256d26d98b02ad599aff49b92192226546c59b17
If somehow we wind up with snapshots with a source suffix, we could wind
up trying to unmap an in-use partition. Detect this case and allow the
snapshot to be deleted without the unmap.
Bug: 183567503
Test: vts_libsnapshot_test
Change-Id: I87dd5bb3a7b9be59dede624924374ccc47b563c2
remove duplicate postsubmit setup, they already run in host-unit-tests presubmit
Change-Id: I4065d7a50729a14911ec64f10082987d3f9ddcfc
Test:presubmit
Bug: 183622274
Do not use the implicit cast from unique_fd to int so
that it is clearer to the reader what the ownership model
is.
Test: pass
Change-Id: I66563eb2bd06f6a712a5afd4c6009f9b25a55de6
Use sorted std:vector instead of std:map to store
the mapping between chunk-id to COW operation.
Addtionally, use shrink_to_fit to cut down vector
capacity when COW operations are stored.
On a full OTA of 1.8G, Anon RSS usage is
reduced from 120MB to 68MB. No variance observed
when merge was in progress.
Bug: 182960300
Test: Full and Incremental OTA - verified memory usage
Signed-off-by: Akilesh Kailash <akailash@google.com>
Change-Id: I50cacbe0d03837a830dedcf9bd0ac9663fc68fa7
Instead of allocating the buffer for the whole
upload (which can be arbitrary number of bytes as
the device determines), read 1 MiB at a time.
Test: pass
Bug: 173654501
Change-Id: Ib601b0341b10b7dccbb429cd21aad86a2d3bfda8
Add worker threads per partition to serve the IO request.
Remove memset of buffer in IO path which was impacting
4k IO performance.
update_verifier performance:
1: ~10-12 seconds with this change (both on full OTA and incremental
OTA); ~70 seconds observed without this changeset
2: ~8 seconds without the daemon once merge is completed
and snapshot devices are removed.
Bug: 181293939
Test: update_verifier, full OTA, incremental OTA
Signed-off-by: Akilesh Kailash <akailash@google.com>
Change-Id: Id90887f3f4a664ee5d39433715d1c166acbd6c60
The parameter "androidboot.hardware" has been removed from bootconfig
and replaced by "hardware" parameter.
Test: launch_cvd with 4.19 and 5.10 kernels
Test: atest CtsFsMgrTestCases
Bug: 173815685
Change-Id: I627426ae1bd0a165b70b8f2584ec184abfb4236f
As parameters are moved from kernel cmdline to bootconfig,
fs_mgr needs to be updated to handle the new location.
/proc/bootconfig should be checked first, if not present, then check
/proc/cmdline.
Test: atest CtsFsMgrTestCases
Test: launch_cvd
Test: launch_cvd with 4.19 kernel artifacts that do not support
bootconfig
Test: Both of the above configurations with --num_instances 0 or 4
Test: Both configurations with androidboot.boot_devices or
androidboot.boot_device set
Bug: 173815685
Change-Id: I23fb07a17c25c9459833cb931ced79d5ccc3e42a
update_engine and libsnapshot must agree on CowOptions parameters,
otherwise the COW size estimation may be incorrect.
Bug: N/A
Test: vts_libsnapshot_test
apply OTA, snapshotctl dump
Change-Id: I219ae458dfa19e4b3c96360d3b847edb2a01ebc8
alignment_offset restrictions were removed in R and are no longer
needed.
Bug: 180571070
Test: liblp_test
Change-Id: I43fa4a929c20cc8c6ec2fece71d5400351c13dbe
I828ce999be6d786bf46dd5655dfda81d046906ab made a slight behaviral change
that fstab is searched and read before /first_stage_ramdisk is mounted
as root. Without this change, the attempt to read fstab from / fails at
the moment, leaving an empty fstab object. But as a side effect of the
attempt, DoCreateDevices() is not called again even after
/first_stage_ramdisk is mounted as root and the fstab is found under /.
This change fixes the problem by adding /first_stage_ramdisk to the list
of places to find the fstab file.
Bug: N/A
Test: Watch TH
Change-Id: I9826610cce436ba706aaea14c9a991822d2bae96
This addresses bugs where unexpected edge cases in the snapshot state
could prevent a merge or data wipe from completing in recovery.
Invalid snapshots (eg on the wrong slot) are now ignored in
CheckMergeState(). This prevents those snapshots from being detected as
"cancelled" and thus falling into RemoveAllUpdateState.
ProcessUpdateState will no longer call RemoveAllUpdateState in recovery.
Furthermore, when RemoveAllUpdateState fails, we will no longer return
the "old" state. If this state is Merging, ProcessUpdateState can
infinite loop.
Finally, HandleImminentDataWipe now guarantees the final state will be
either MergeFailed or None. For testing purposes, the old mechanism was
too susceptible to state machinery changes. And for practical purposes,
either we're going to wipe data (which removes the OTA), or a merge
failed and we can't. So the effective outcome is always no update or a
failed update.
Bug: 179006671
Test: vts_libsnapshot_test
Change-Id: Idcb30151e4d35cbeccf14369f09707ae94a57c66
QuerySnapshotStatus assumes IsSnapshotDevice() would return true.
Additionally, recovery does not have access to /dev/loop-control, which
cannot be used by libfiemap anyway. Access it on-demand instead of
preemptively.
Bug: N/A
Test: manual test
Change-Id: I0f746870d7a8ec6d666f0bdd2fef3464b214928b
