On Sep 25, 2013, at 8:56 AM, Ric Wheeler <rwhee...@redhat.com> wrote:
> On 09/25/2013 10:48 AM, Chris Murphy wrote: >> On Sep 25, 2013, at 6:12 AM, Ric Wheeler <rwhee...@redhat.com> wrote: >>> We should not confuse TRIM that gets handled at the device layer (and is a >>> slow, non-queued S-ATA command for example) and a dm-thin parsing of that >>> same command in software which just updates the metadata that dm-thin >>> maintains. >> Yes, fair point. I should have qualified the assertion better to indicate >> default discard to the physical device is probably not a good idea. Or maybe >> it needs to get smarter, and initiated when the fs isn't particularly busy. >> A kind of delayed discard. >> >> >> Chris Murphy > > We do have fstrim - you run it periodically on an online file system and it > sends down larger discard requests. That is actually pretty much always the > best way to go. Understood. I'm thinking of something like fstrim, but more automatic so the user doesn't have to either initiate or schedule it. Lazy discard, i.e. during idle time. But it's probably specious for me to suggest a solution for a problem that's not that well understood. There's much fractionation in SSD land, largely due to firmware not hardware differences, and then use cases that may not be aligned due to flawed marketing or pricing incentives. It's sorta amusing to me, Windows 7 pretty much always enables TRIM to physical device by default, whereas Apple pretty much never does unless it's their own branded (and firmwared) SSD. At least Windows has a command to enable/disable, Apple provides nothing obvious even at the command line to manage this, even manually like an fstrim equivalent. So even those companies have different views on the use of discard. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
