From: Luca Boccassi Date: Fri, 19 Dec 2025 13:19:16 +0000 (+0000) Subject: core: reuse existing dm-verity device for single filesystem images pinned by policy... X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=059b3b466dda2d3b6f667b3b6635644d039afe11;p=thirdparty%2Fsystemd.git core: reuse existing dm-verity device for single filesystem images pinned by policy (#40007) Loading images is, generally speaking, the slowest part of sd-executor when spawning a service. This is due to multiple factors. dm-verity is obviously a big part of the cost, but dissecting in general via libblkid also can take a lot of time, due to probing the images and their filesystems. A performance test doing service restarts in a row shows these results, ran on a production system (low power and slow ARM64 SOC) with a real production service, show the following service interruption intervals: ``` Count | P50 (ms) | P90 (ms) | P95 (ms) | P99 (ms) | P99.9 (ms) 507 | 1,532 | 1,726 | 2,548 | 4,112 | 4,592 ``` One iteration is 507 restarts in this case, but this has ran hundreds of times and the results are always in line within margin of error. This also holds true for metrics from live systems, same numbers. Between 1.0s and 1.2s can be attributed by profiling to the time needed for the service code itself to start up and sd_notify, the rest is spent inside systemd's code. This means there is currently a tradeoff for services - either use secure images, or make restarting fast. Downtime of services is a very important metric, as for many cases this directly translates to outages, total or partial (blackouot or greyout). In order to facilitate using secure images without downsides, skip the slow dissect steps (probing, loop devices, etc) when the configured image is a single filesystem dm-verity image with a policy that pins it to a single filesystem, and an already existing and open dm-verity device can be found and reused. This allows orchestrators to pre-open images on download, before restarting services, to minimize downtimes. --- 059b3b466dda2d3b6f667b3b6635644d039afe11