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

On Mon, 2009-08-17 at 14:21 -0400, Greg Freemyer wrote:

On Mon, Aug 17, 2009 at 1:19 PM, James Bottomley[off-list ref] wrote:

quoted

On Mon, 2009-08-17 at 13:08 -0400, Greg Freemyer wrote:

quoted

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.

Maybe I misunderstood Jim Owens previous comment that designing for
devices that only meet the spec. was not his / Linus'es preference.

Instead they want to have a whitelist enabled list of drives that
support trim / ncq without having to drain the queue.

There's no way to do this.  The spec explicitly requires that you not
overlap tagged and untagged commands.  The reason is fairly obvious:
you wouldn't be able to separate the completions.

I just re-read his post and he did not explicitly say that, so maybe
I'm mis-representing it.

quoted

quoted

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

quoted

mdraid with SSD storage used to build raid5 / raid6 arrays

Non-coalescing is believed detrimental,

It is?  Why?

For the only compliant SSD in the wild, Mark has shown it to be true
via testing.

He only said larger trims take longer.  As I said previously, if it's a
X+nY relationship, then we still benefit from accumulation up to some
value of n.

For Enterprise SCSI, I thought you said a coalescing solution is
preferred.  (I took that to mean non-coalescing is detremental.  Not
true?).

I'm trying to persuade the array vendors to speak for themselves, but it
seems that UNMAP takes time.  Of course, in SCSI, this is a taggable
command so we don't have the drain overhead ... but then we can't do
anything that would produce an undetermined state based on out of order
tag execution either.

For mdraid, if the trims are not coalesced mdraid will have to either
ignore them, or coalesce them themselves. Having them come in bigger
discard ranges is clearly better.  (ie. At least the size of a stripe,
so it can adjust the start / end sector to a stripe boundary.)

If we did discard accumulation in-kernel (a big if), it would likely be
at the request level; thus md and dm would automatically inherit it.
dm/md are a problem for a userspace accumulation solution, though
(although I suspect the request elevator can fix that).

quoted

quoted

 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.

I missed XFS_TRIM somehow.  What benefit does XFS_TRIM provide at a
high level?  Is it part of the realtime delete file process, or an
after the fact scanner?

It guarantees that trim does not overlap allocations and writes on a
running system, so it gives us safety of execution.

James