On Fri, Aug 14, 2009 at 5:56 PM, Roland Dreier<rdreier@xxxxxxxxx> wrote: > > > It seems to me that unmap is not all that different, why do we need to > > do it even close in time proximity to the deletes? With a bitmap, we > > have total timing control of when the unmaps are forwarded down to the > > device. I like that timing control much better than a cache and > > coalesce approach. > > The trouble I see with a bitmap is the amount of memory it consumes. It > seems that discards must be tracked on no bigger than 4KB sectors (and > possibly even 512 byte sectors). But even with 4KB, then, say, a 32 TB > volume (just 16 * 2TB disks, or even lower end with thin provisioning) > requires 1 GB of bitmap memory. Which is a lot just to store, let alone > walk over etc. Have the filesystem guys created any efficient extent tree tracking solutions? I mean a 16TB filesystem obviously has to track the freespace somehow that does not require 1GB of ram. Can that logic be leveraged in block to track freespace? That obviously assumes its not too cpu intensive to do so. If a leaf in the extent tracking tree becomes big enough, it could even be sent down from the block layer and that leaf deleted. ie. If a leaf of the tree grows to represent X contiguous blocks, then a discard could be sent down to the device and the leaf representing those free blocks deleted. The new topo info about block devices might be able to help optimize the minimum size of a coalesced discard. Greg -- Greg Freemyer -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
