JLS2009: A Btrfs update [LWN.net]

JLS2009: A Btrfs update

Posted Oct 29, 2009 14:03 UTC (Thu) by droundy (subscriber, #4559)
Parent article: JLS2009: A Btrfs update

Anybody who has had to replace a drive in a RAID array knows that the rebuild process can be long and painful. While all of that data is being copied, the array runs slowly and does not provide the usual protections. The advantage of running RAID within Btrfs is that the filesystem knows which blocks contain useful data and which do not. So, while an MD-based RAID array must copy an entire drive's worth of data, Btrfs can get by without copying unused blocks.

Isn't this something that could be achieved in an ordinary RAID if filesystems supported the TRIM feature that has been touted for SSDs?

Does anyone know if this is being worked on?

(Log in to post comments)

JLS2009: A Btrfs update

Posted Oct 29, 2009 20:19 UTC (Thu) by bronson (subscriber, #4806) [Link]

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.

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...