Installer should detect SSD drive presence and set lvm issue_discards=1 config option itself

[tlaurion]

Qubes OS version:

R3.2, R4.0

Affected component(s):

dom0

---

Steps to reproduce the behavior:

Use Qubes intenseively. lvm_thin will use too much space compared to what is actually used on disk.

Expected behavior:

Disk space should be related to what is actually used.
Documentation specifies what should be done by user. It should be the installer's job to set the configuration option instead.

Actual behavior:

Disk space is filled until all disks are remounted RO.

General notes:

Documentation specifies what should be done by user. It should be the installer's job to set the configuration option instead.

---

Related issues:

[marmarek]

lvm.conf issue_discards=1 settings is relevant for SSD wear leveling, but not really for free space on lvm_thin. As noted in the documentation, all parts required for lvm_thin space calculation are already done by Qubes 4.0 installer (some fixes are part only of 4.0rc5, so if you have older version, you may need to enable fstrim.timer manually).
On 3.2 LVM thin volumes are not used (and even if you install with lvm_thin, all VMs are in dom0 filesystem as files), so this is not really needed. Unless you heavily customize storage layer manually.

The thing that is not done automatically, is passing this down to SSD disk. Doing this might help with some attacks on LUKS layer (reveal data layout, but not really data itself). See the article linked in the documentation. So, this is a trade-off between security and SSD life time. We choose to have safer default.

[marmarek]

lvm.conf issue_discards=1 settings is relevant for SSD wear leveling, but not really for free space on lvm_thin. As noted in the documentation, all parts required for lvm_thin space calculation are already done by Qubes 4.0 installer (some fixes are part only of 4.0rc5, so if you have older version, you may need to enable fstrim.timer manually).
On 3.2 LVM thin volumes are not used (and even if you install with lvm_thin, all VMs are in dom0 filesystem as files), so this is not really needed. Unless you heavily customize storage layer manually.

The thing that is not done automatically, is passing this down to SSD disk. Doing this might help with some attacks on LUKS layer (reveal data layout, but not really data itself). See the article linked in the documentation. So, this is a trade-off between security and SSD life time. We choose to have safer default.

[awokd]

Should we downgrade the "is recommended if using an SSD" to something like "you may wish to [...] if using an SSD"?

[awokd]

Should we downgrade the "is recommended if using an SSD" to something like "you may wish to [...] if using an SSD"?

[andrewdavidwong]

Should we downgrade the "is recommended if using an SSD" to something like "you may wish to [...] if using an SSD"?

This sounds like the right approach, but Marek's point should be made explicit. ("So, this is a trade-off between security and SSD life time. We choose to have safer default.") It sounds like the installer is choosing the safer default, while the documentation is currently advising the user to opt for a less-safe configuration. Not good!

[andrewdavidwong]

Should we downgrade the "is recommended if using an SSD" to something like "you may wish to [...] if using an SSD"?

This sounds like the right approach, but Marek's point should be made explicit. ("So, this is a trade-off between security and SSD life time. We choose to have safer default.") It sounds like the installer is choosing the safer default, while the documentation is currently advising the user to opt for a less-safe configuration. Not good!

[awokd]

less-safe

I think it's splitting hairs to an extent, but will refer back to that linked article in my edit.

[awokd]

less-safe

I think it's splitting hairs to an extent, but will refer back to that linked article in my edit.

[marmarek]

It really depends on the threat model. My understanding is, based on the information revealed by the TRIM/DISCARD operation you can get used/free space. In practice, you can get from this a number and sizes of VMs (if you're lucky, because of blocks allocation by LVM thin/dom0 filesystem). Some don't consider this information to be sensitive, to the extend of publishing it explicitly: https://blog.invisiblethings.org/2011/03/13/partitioning-my-digital-life-into.html

But yes, changing "recommended" to "you may want" is a good idea.

[marmarek]

It really depends on the threat model. My understanding is, based on the information revealed by the TRIM/DISCARD operation you can get used/free space. In practice, you can get from this a number and sizes of VMs (if you're lucky, because of blocks allocation by LVM thin/dom0 filesystem). Some don't consider this information to be sensitive, to the extend of publishing it explicitly: https://blog.invisiblethings.org/2011/03/13/partitioning-my-digital-life-into.html

But yes, changing "recommended" to "you may want" is a good idea.