On Tue, Nov 11, 2008 at 12:07:17PM -0500, jim owens wrote: > I agree with you. Thus my earlier assertion: > > - trim/unmap for SSD garbage collection has a different goal > than trim/unmap for thin provisioning. Yes, I agree. > In the Thin Provision mode, we want to delay them as you said: > >> 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, > > to be filesystem friendly. > > But this won't change the block layer. This is a per-filesystem > coding issue to decide when to send the discard. Yes. But for this latter case large (or less so odd) unmap size aren't that bothersome. For the SSD use case they would be. Note that filesystems will need some SSD-awareness ayway, e.g. I have a local hack for XFS that never bothers to look for extents in the by-bno indexed, and I'm currently prototype a version that doesn't even update it (could be converted back to a regular one using repair) > > jim > -- > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html ---end quoted text--- -- 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
