Hello all,
I am working as a contractor for the GNOME Foundation to integrate
systemd-homed into the GNOME desktop and related components, as part of
a grant by the Sovereign Tech Fund[1]. systemd-homed is a component of
systemd that, among other things, puts each user's home directory into a
separate LUKS volume so that each user can have their data encrypted
independently.
I have recently come across a blog post from Cloudflare[2] that details
a significant (~2x) improvement to throughput and latency that they were
able to achieve on dm-crypt devices by implementing[3] and using the
no_read_workqueue and no_write_workqueue performance flags. These flags
bypass queuing that was in place to optimize for access patterns of
spinning media and work around limitations of kernel subsystems at the time.
Thus, to me it looks like these flags should default to on for SSDs
(i.e. /sys/block/<name>/queue/rotational is 0). Such a distinction based
on the type of storage media has precedent (i.e. selecting the `none` IO
scheduler for SSDs to improve throughput). So, I was going to change
systemd to turn these flags on when it detected an SSD, but I spoke to
the maintainers first and they suggested that I try to implement this in
cryptsetup instead. So I reached out there[4], and they suggested that I
should write to you, and that the kernel should set optimal defaults in
cases like this. They also mentioned recalling some hardware
configurations where these flags shouldn't be on.
Is there some reason these two flags aren't on by default for SSDs?
Thanks,
Adrian
[1]:
https://foundation.gnome.org/2023/11/09/gnome-recognized-as-public-interest-infrastructure/
[2]: https://blog.cloudflare.com/speeding-up-linux-disk-encryption/
[3]:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/md/dm-crypt.c?id=39d42fa96ba1b7d2544db3f8ed5da8fb0d5cb877
[4]: https://gitlab.com/cryptsetup/cryptsetup/-/issues/862
