[systemd-devel] systemd-repart very slow creation of partitions with Encrypt=
Valentin David
valentin.david at canonical.com
Mon Jun 5 08:46:09 UTC 2023
I think that behavior was introduced by
https://github.com/systemd/systemd/commit/48a09a8fff480aab9a68e95e95cc37f6b1438751
On Mon, Jun 5, 2023 at 10:41 AM Valentin David <valentin.david at canonical.com>
wrote:
>
>
> On Mon, Jun 5, 2023 at 9:56 AM Lennart Poettering <lennart at poettering.net>
> wrote:
>
>> On So, 04.06.23 14:25, Valentin David (valentin.david at canonical.com)
>> wrote:
>>
>> > I have been trying to create a root partition from initrd with
>> > systemd-repart. The repart.d file for this partition is as follow:
>> >
>> > [Partition]
>> > Type=root
>> > Label=root
>> > Encrypt=tpm2
>> > Format=ext4
>> > FactoryReset=yes
>> >
>> > I am just using systemd-repart.service in initrd, without modification
>> > (that is, it finds the disk from /sysusr/usr). Even though this is
>> working,
>> > the problem I have is that it takes a very long time for the partition
>> to
>> > be created. Looking at the logs, it spends most of time in the
>> > reencryption.
>>
>> reencryption? We don't do any reencrytion really. i.e. we do not
>> actually support anything like "cryptsetup reencrypt" at all. All we
>> do is the equivalent of "cryptsetup luksFormat". Are you suggesting
>> that repart is slower at formatting a block device via LUKS than
>> invoking cryptsetup directly would be? I'd find that very surprising...
>>
>
> This is what it looks like in src/partition/repart.c. Function
> partition_encrypt calls sym_crypt_reencrypt_init_by_passphrase and then sym_crypt_reencrypt.
> And make_filesystem is called before partition_encrypt. So it must
> reencrypt since mkfs was called before.
>
>
>> > For 11GB partition on a VM, it takes more than 2 minutes. On the bare
>> metal
>> > with a 512 GB nvme disk, it has been running for 3 hours. And it is
>> still
>> > not finished.
>>
>> This is really strange. The LUKS formatting should just write a
>> superlock onto the disk, which is just a couple of sectors, and should
>> barely take any time.
>>
>> Or are you saying "mke2fs" takes that long?
>>
>> Note that we specify lazy_itable_init=1 during formatting ext4, hence
>> it should actually be super fast too...
>>
>
> No. mkfs was done. In the logs it was all about reencryption. See
> https://gitlab.gnome.org/-/snippets/5809/raw/main/snippetfile1.txt
>
>
>>
>> > I do not think cryptsetup reencryption supports holes. Is it normal to
>> have
>> > a full reencryption of a disk that was just initialized with mkfs.ext4?
>> If
>> > so, could we at least move the effective reencryption after
>> > systemd-repart.service, so that the rest of the system can continue to
>> boot?
>> >
>> > I am running:
>> > systemd 253.4 running in system mode (+PAM +AUDIT +SELINUX +APPARMOR
>> +IMA
>> > +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS
>> +FIDO2
>> > +IDN2 -IDN -IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 +PWQUALITY
>> +P11KIT
>> > -QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMM
>> > ON +UTMP +SYSVINIT default-hierarchy=unified)
>> >
>> > Cryptsetup: v2.6.1
>>
>> I am a bit puzzled by this. WOuld be good to figure out what actually
>> is so slow here? formatting luks? formatting ext4? discarding?
>>
>> Lennart
>>
>> --
>> Lennart Poettering, Berlin
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20230605/af5636cd/attachment.htm>
More information about the systemd-devel
mailing list