I was having performance issues downloading at 1 Gbps to my fully encrypted 3500 MB/s NVMe, which left the system unresponsive for a second or two, specially with Steam that does CPU and I/O intensive tasks while downloading games, related to decompressing and shaders processing.
I found this article from Cloudflare claiming that dm-crypt queuing is an unnecessary overhead with fast storage: Speeding up Linux disk encryption
If not, the bottleneck is maybe using AES for disk encryption (it is used by default as most models have it). If the kernel cannot use a hardware-implementation (which is AES-NI), it has to fall back to a software implementation, which is a strong bottleneck (the bugzilla report below contains a comparison as example).
You can check with lscpu or lscpu | grep aes (there has to be a flag âaesâ) or by checking your CPU model on the vendor website.
none, the default for NVMe, the first thing I did was trying to change it to bfq and it helped with responsiveness but decreased throughput, changing dm-crypt flags was the best solution overall
I agree. While this is just anecdata, overall performance seems to be better with the flags set, and this is especially noticeable when dnf update is installing a large package like kernel-headers.
I just added the lines to the /etc/crypttab with an Enter before.
sudo dracut --regenerate-all --force â 1
dracut: Can't write to /boot/efi/762dea3743ad4b369882c46e6992d7e9/6.2.13-300.fc38.x86_64: Directory /boot/efi/762dea3743ad4b369882c46e6992d7e9/6.2.13-300.fc38.x86_64 does not exist or is not accessible.
I am on Fedora Kinoite (kinoite-main from ublue) so this will probably be different. Would just updating to a new image fix the issue, as dracut will be reloaded?
Iâm currently using Silverblue and initramfs seems to be handled different, so I did this:
$ sudo dmsetup table
When the flags are enabled youâll see allow_discards no_read_workqueue no_write_workqueue at the end, probably thatâs not the case after editing crypttab. You have to copy the device name from the output, itâs in the first column luks-blablabla, then you can run:
I played around some with the no_read_workqueue and no_write_workqueue options but they donât result in any meaningful performance difference for me. I benchmarked the disks before and after setting these options and the results are very similar. I did have allow_discard enabled during the benchmarks, that one is probably useful but is a bit difficult to benchmark and depends greatly on the trim implementation of the disk.
Reading benchmark using fio with a buffer size of 1KB
I disagree, Badly written Docs are the same as not having any. Badly written, can have the potential for mishaps and a bad experience. An example of this is the akmods + 5mins + other things for secureboot ordeal most users stumble over.
Also, the arduous update process of the Quick Docs or the GitLab vs. Pagure is VERY disillusioning. If we the community need Quick Docs, letâs write them ourselves. We can use the current doc as a basis.
It is worse. Badly written Docs content belongs to the reasons why people loose trust in Docs at all, and thus badly written Docs pages can cause damage also to other Docs contents. (I intentionally leave the definition of âbadly writtenâ open as this simplification can be used to describe many issues in Docs history and related discussions, but I would add that âbadly writtenâ is complemented by âbadly maintainedâ, which should also always be considered)
I suggest to get in touch with the Docs team before organizing Docs stuff. I suggest to contact them with a dedicated topic or at the best, on Matrix: https://chat.fedoraproject.org/#/room/#docs:fedora.im if you are interested.
Also, please be more careful about tagging. You can open a docs-team topic and make them aware of your suggestions and link to this one - then the new one will be a docs-team topic. But just adding the tag to a topic that is not explicitly intended for docs-team might cause work, as one of them would then need to read throughout this topic to find out what this is about and why it is about docs-team - it is thus likely that it will be ignored and thus just blurs the tag in the end. This tag might also make it harder to find this topic if people are interested in its content (technical content about NVMe performance and what/why to make Fedora defaults - not how and when to write a Docs page about it and how/who to maintain it). Team tags are for teams, and team topics are dedicated to organize the very team and its tasks: this topic definitely had a different purpose.
Imho, this post and everything later/below belongs to a new topic, in which you could make a proposal/request/suggestion in/to the Docs team and get in touch with them about if/when/why to do something in this respect (or not, whatever). In that new topic, you could link to here.
PR create work. And if PR are not appropriate or not intended, they cause unnecessary /avoidable work. One issue the Docs team has had throughout its history is a lack of human resources compared to the amount of tasks that are allocated to them and compared to what they wanted to achieve.
Creating new Docs pages (and when and how) is something that should contain some considerations, and it should be aligned/coordinated with the team before publicly encouraging people (especially as this topic currently creates a little the perception that this encouragement comes from the Docs team). Again, please get in touch with the Docs team before doing that. Iâm quite sure they would be thankful for any contributor. Even handling and âpre-processingâ PR could be valuable. When I was there, we had periods when some PR were unprocessed for months because no one had the time to process them, although I do not know if this is still a critical issue (and why / why not). But actions and encouragements for actions have to be coordinated and aligned.
The fourth field, if present, is a comma-delimited list of options.
discard,no-read-workqueue,no-write-workqueue
EDIT:
These options can be stored in the LUKS2 header / metadata instead. TBH Iâm not even sure if the crypttab file is necessary if you have only root in it (on Arch itâs empty), I read somewhere that root is always mounted but I canât find it now.
