| |||||||||||||
JLS2009: A Btrfs updateJLS2009: A Btrfs updatePosted Oct 29, 2009 20:19 UTC (Thu) by bronson (subscriber, #4806)In reply to: JLS2009: A Btrfs update by droundy Parent article: JLS2009: A Btrfs update
Well, SSDs have hardware to track allocations anyway. The trim command just manipulates that.
Regular hard disks are basically big platters of bits. They don't have any allocation tracking. Because implementing a generic (filesystem-agnostic) trim would require adding another software layer and allocating space to bitmaps, I think it's unlikely the benefits would be worth the complexity.
But who knows! It's a little hard to predict the future of storage right now.
(Log in to post comments)
JLS2009: A Btrfs update Posted Oct 29, 2009 22:30 UTC (Thu) by filteredperception (guest, #5692) [Link]
Just a week ago I asked dm-devel about the narrow case of dm-snapshot optimally responding to discard-requests. Simply discarding unneeded exception chunks to optimize the amount of cow storage used. I have yet to get any buy-in. One response I did get was about snapshot-origin, which in the article is the lvm snapshot 10minute vs 2 seconds example. For snapshot-origin and other raids, it does as you say require additional bitmap/mask storage and complexity. But for just dm-snapshots, I think it is really simple and beneficial to take advantage of discard requests (unless of course there is some preclusive aspect I don't grok yet). The big benefit I'm interested in is the Fedora/CentOS persitent LiveUSB, utilizing dm-snapshot instead of the more typical unionfs. Currently dm-snapshot suffers in file create/delete problem of cow blocks being used for blocks the filesystem doesn't care about any longer. But if discard-requests can fix that...
https://www.redhat.com/archives/dm-devel/2009-October/msg...
|
|||||||||||||