Sorry for beeing so late to the game, been on the road for a couple of days. Why do most people assume that sending unmap/trim commands for every deletet extent ASAP is a good idea? What this means is that we basically duplicate the space allocator in the array. Everytime we free something we don't just have to do a local btree insert in the filesystem code but another behind a couple of abstractions, and similarly on each allocation the storage device would have to allocate from it's pool. Worth off all the interesting preallocation optimization we've done in the filesystem, be thos explicit pre-allocation from the application or implicit ones in the allocator will be lost due to the abstraction boundary. So I think not actually doing these on every alloc/free is a good idea. Instead the filesystem would free bits when big enough regions happen, which is something simple enough to do with most btree implementations. That is of course not an excuse for just having the UNMAP as a hint. I think having the UNMAP a an exact operation that is either guaranteed to release the underlying space or fail will make the whole storage setup a lot more robust. And while odd "unmap block" sizes will make it a lot harder for the filesystem I think we could find ways to deal with them, even if it might be ugly in places. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
