Hi everyone, Ric proposed a similar topic already [1], but I'd like to just add a little more to that discussion with a broader proposal for discussing discard. Proposal: Discard is a topic that seems to need a little bit of TLC from the kernel side. The two main approaches with discard are either to enable it as a mount option or to periodically run fstrim. At Facebook, we've seen performance wins with both enabling discard and disabling discard in favor of fstrim. I would like to find a middle ground where we don't have to have application developers performance tune for the hardware. XFS has had async discard support, but it has been problematic for our fleet. We were seeing bursts of large discard requests caused by async discard in XFS. This resulted in degraded drive performance increasing latency for dependent services. An alternative to discard is a filesystem level choice of reusing blocks. Rather than immediately issuing a discard, we can choose to reuse a block which will cause the underlying FTL to invalidate a block that we would have discarded. This saves the work done by the initial discard. There will have to be a balance here though with saving discard with hopes of reusing it and eventually issuing the discards. Another issue is each drive has its own proprietary FTL which introduces a wide variability of performance with discard. Some drives don't need discard to perform well and others need discard enabled. There is also a class of drives where discard is so not performant that it locks up the drive. I would like to discuss how we can quantify this and help tune discard within the kernel. In summary, I'd like to explore discard more and understand how we can build a more balanced discard experience where end users don't have to be super cognizant of the implications on their applications. [1] https://lore.kernel.org/linux-fsdevel/92ab41f7-35bc-0f56-056f-ed88526b8ea4@xxxxxxxxx/ Thanks, Dennis
