Messages in this thread | | | Subject | Re: Discard support (was Re: [PATCH] swap: send callback when swap slot is freed) | From | James Bottomley <> | Date | Mon, 17 Aug 2009 17:19:35 +0000 |
| |
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
| |