We should consider discard=asyncby default on all baremetal installations; and coordinate with upstream about making it a default there too.
discard=async
Summary:
How to implement:
We can do this in kickstart using --fsoption discard=async which will enable it during installation and add it to /etc/fstab.
--fsoption discard=async
Overly verbose background and extras in this now closed RFE: kickstart option to control discard configuration
Should we use discard=async for NVMe SSD's as well? Or periodic TRIM is preferable for NVMe devices?
The discard mount option (both sync and async) will discard metadata blocks, and it happens fairly soon after blocks are freed. Those blocks might be needed by 'usebackuproot' if there's a crash or powerfailure. It's trivially reproducible (locally) to discover that those backuproots are all zeros if either discard mount option is enabled.
discard
I'm inclined to say we should stick with just fstrim.timer as the primary way discards get issued. Once a week is surely often enough for the vast majority of workloads. And leave it up to case by case basis for enabling the discard mount option.
If it's possible to issue discards only to data blocks, that would be better.
Neither the discard section nor the usebackuproot section in man 5 btrfs mention this. I wonder if it is intentional. Perhaps it would be worth the effort to file a request for btrfs developers to either implement data-only discard option, or to make sure that backuproot metadata are not discarded immediately (but later, compared to all other blocks). It might even be a bug.
man 5 btrfs
Upstream definitely knows about it. I may have overstated the value of usebackuproot because it shouldn't ever be needed, it's really a work around for buggy firmware to try to get back to a (hopefully) known good root in case write ordering got messed up by the firmware.
usebackuproot
While most drives do honor write ordering properly, and can use discard safely, I think the overwhelming majority of users are adequately and well served by the default weekly fstrim. And that the incremental improvement of discard applies to few cases in Fedora compared to the risk for those who have buggy drives and untimely crash/power fail. I am really on the fence, and not opposed to discard by default but I'm inclined to be more conservative and let upstream lead on when discard should become the default. And right now it isn't.
Perhaps this is best dealt with documentation of mount options that aren't enabled by default but are recommended for specific use cases?
Metadata Update from @ngompa: - Issue set to the milestone: Future Release (was: Fedora 34)
At today's Fedora Hatch event, @masonchrislo was talking about discard=async and how he considers it pretty reasonable to activate by default when we detect that Btrfs is being put onto an SSD. We may want to revisit this and see if we can make fstrim.timer more intelligent to not collide with Btrfs.
fstrim.timer
I'd rather see the kernel do it at the same time (and logic) it enables ssd optimizations, than sticking it in fstab.
This is queued for Linux 6.2: https://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git/commit/?h=for-next&id=4d542835e8d1e43282c83c1a0395b209bdadd475
We should ensure fstrim.timer isn't going to cause a problem here.
It's expected they can co-exist.
https://lore.kernel.org/linux-btrfs/20220727174726.GU13489@suse.cz/
Then we have nothing to do but wait. :100:
Metadata Update from @ngompa: - Issue assigned to ngompa
This is coming in with the Linux kernel 6.2 rebase. :tada:
Metadata Update from @ngompa: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.