Re: systemd-repart very slow creation of partitions with Encrypt=

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxx> wrote:


On Mon, Jun 5, 2023 at 9:56 AM Lennart Poettering <lennart@xxxxxxxxxxxxxx> wrote:
On So, 04.06.23 14:25, Valentin David (valentin.david@xxxxxxxxxxxxx) 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

[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux