On Tue, May 08, 2012 at 08:52:07AM -0700, Dan Williams wrote:

On Tue, May 8, 2012 at 3:16 AM, Shaohua Li [off-list ref] wrote:

quoted

quoted

quoted

Writing the parity disk is worse. Discard is to improve the garbage
collection
of SSD firmware, so improve later write performance. While write is bad for
SSD, because SSD can be wear leveling out with extra write and also write
increases garbage collection overhead. So the result of small
discard is data
disk garbage collection is improved but parity disk gets worse and
parity disk
gets fast to end of its life, which doesn't make sense. This is even
worse when
the parity is distributed.

Neil,
Any comments about the patches?

ping!

So, are we still in the position of needing to degrade individual
stripes to support trim?  Is there any benefit to making this a
temporary condition?  I.e. trim large ranges, including the parity
disk, and then once all the trim sequences have coalesced resync the
stripes that remain only partially trimmed?

Yes, we need trim a whole stripe one time. This is the best I can do now.
resync involves write and I don't want to do any unnecessary write, because
trim is to improve ssd firmware garbage collection while write goes to the
oppositive and makes flash wear out faster.

Or your suggestion is if a trim is small (for example, only covers one disk),
we don't do trim immediately but just record it in bitmap. Later if the small
trim can be coalesced to one strip, trim the strip. This is optimal but
involves disk format change. And to make it efficient, we need track 4kB range.
From Neil's blog, there isn't such space left.

Thanks,
Shaohua