So far upstream fs developers have been reluctant to make 'discard' mount option the default or autodetected. When discards happen to fast, many consumer SSDs become busy with garbage collection, either hanging on the operation or resulting in performance stalls. When discards don't happen at all, some consumer SSDs can get stuck doing on-demand erase block erasures, and become slow.
Btrfs offers a new implementation, discard=async. The goal is to provide discard hinting, but at a slower rate that doesn't cause conflicts with metadata and data writes.
Discard mount option is likely only applicable to host computers with SSD drives.
Contra use case:
Virtual machine (guests) might not want this option set, because it will result in fallocated backing files becoming sparse files. Other setups, using LVM (thick or thin) might want this option set.
Provide a means to explicitly set or unset the proper option by kickstart command, probably per mount point, with persistent enablement happening in /etc/fstab (or systemd native unit file, as appropriate).
--discards=default - use file system default. This would be the Anaconda default if not explicitly used for a given mount point.
--discards=on - use mount option discard on xfs, ext4, use discard=async on btrfs
--discards=off - use mount option nodiscard on xfs, ext4, btrfs
Arguably --discards=default doesn't need to exist, but I'm not sure of the style/semantics. If it's not needed, great.
Another possibility is some kind of condition check that chooses on/off. This would mean the installer can just figure it out. e.g.
--discard=auto If the condition check sees both SSD and not a virtual machine guest, then discard=on. Otherwise, discard=default (or possibly discard=off).
I think the '--fsoptions FSOPTS' argument for part should work fine for this: https://pykickstart.readthedocs.io/en/latest/kickstart-docs.html#part-or-partition
I'd really like to try to avoid piling on more options unless they are absolutely needed.
Understood. Is it possible in kickstart to test for some condition, so that the option is used only for those conditions? i.e. only if the file system is btrfs, not if it's in a VM, not if the target is rotational (or other test that discards are supported). I think those three are everything.
(In reply to Chris Murphy from comment #4)
> Understood. Is it possible in kickstart to test for some condition, so that
> the option is used only for those conditions? i.e. only if the file system
> is btrfs, not if it's in a VM, not if the target is rotational (or other
> test that discards are supported). I think those three are everything.
No, and that's not something that we'll be adding :) The way people usually handle that is via %pre scripts and %include but even then that's a bit of a hack.
As written in comment 0, this would really span anaconda, pykickstart, and python-blivet.
Taking only a subset of the RFE, Brian says that from pykickstart point of view, there is already a way to provide the raw fstab options string. The kickstart would look something like this:
> part (...) --fsoptions "discard=async"
But with conditional enablement, the scope expands: The right place to decide if the option would be set is the blivet library which handles actual storage manipulation. And of course anaconda would have to glue that with the rest of the works.
I wonder if it's possible, and more appropriate, to do this by udev rule injecting the mount option? It would be much less discoverable to the user, but I'm not convinced it's a significant negative *if* the condition checking is reliable, and the applied policy is correct.
We have similar problems elsewhere, e.g. "rotational" detection is not reliable. USB sticks report they're rotational, as do virtioblk (/dev/vda) devices.
I would argue for not making this behave differently based on whether the host is a VM or not. Not only can it make some future reproducers difficult, but the hypervisor itself should be intelligent enough to only enable the discards to go through when it wants to (e.g. thin provisioning), but not for fully allocated disks.
(In reply to Martin Kletzander from comment #8)
> the hypervisor itself should be intelligent enough to only
> enable the discards to go through when it wants to
It's a persuasive argument.
Also, for reference:
Consolidating btrfs issues for design and planning logics. This issue is now found here:
#6 enable discard=async by default