Re: thin provisioned LUN support

Christoph Hellwig
2008-11-11T17:33:45Z

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@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
---end quoted text---