Re: Discard support (was Re: [PATCH] swap: send callback when swap slot is freed)

From: James Bottomley
Date: Mon Aug 17 2009 - 13:19:58 EST


On Mon, 2009-08-17 at 13:08 -0400, Greg Freemyer wrote:
> All,
>
> Seems like the high-level wrap-up of all this is:
>
> There are hopes that highly efficient SSDs will appear on the market
> that can leverage a passthru non-coalescing discard feature. And that
> a whitelist should be created to allow those SSDs to see discards
> intermixed with the rest of the data i/o.

That's not my conclusion. Mine was the NCQ drain would still be
detremental to interleaved trim even if the drive could do it for zero
cost.

> For the other known cases:
>
> SSDs that meet the ata-8 spec, but don't exceed it
> Enterprise SCSI

No, SCSI will do WRITE_SAME/UNMAP as currently drafted in SBC3

> mdraid with SSD storage used to build raid5 / raid6 arrays
>
> Non-coalescing is believed detrimental,

It is? Why?

> but a regular flushing of the
> unused blocks/sectors via a tool like Mark Lord has written should be
> acceptable.
>
> Mark, I don't believe your tool really addresses the mdraid situation,
> do you agree. ie. Since your bypassing most of the block stack,
> mdraid has no way of snooping on / adjusting the discards you are
> sending out.
>
> Thus the 2 solutions that have been worked on already seem to address
> the needs of everything but mdraid.

I count three: Mark Lord script via SG_IO. hch enhanced script via
XFS_TRIM and willy current discard inline which he's considering
coalescing for.

James

> Also, there has been no discussion of dm based volumes. (ie LVM2 based volumes)
>
> For mdraid or dm it seems we need to enhance Mark's script to pass the
> trim commands through the full block stack. Mark, please cmiiw
>
> Greg


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/