From: Shaohua Li <shli@kernel.org>
To: Dan Williams <dan.j.williams@intel.com>
Cc: NeilBrown <neilb@suse.de>,
linux-raid@vger.kernel.org, axboe@kernel.dk,
Shaohua Li <shli@fusionio.com>
Subject: Re: [RFC 1/2] MD: raid5 trim support
Date: Wed, 9 May 2012 11:12:32 +0800 [thread overview]
Message-ID: <20120509031232.GA507@kernel.org> (raw)
In-Reply-To: <CABE8wwtZKrerxq4OFGnjUOgjvRb-6FNWdgUkiVwUVuV-uycv6Q@mail.gmail.com>
On Tue, May 08, 2012 at 08:52:07AM -0700, Dan Williams wrote:
> On Tue, May 8, 2012 at 3:16 AM, Shaohua Li <shli@kernel.org> wrote:
> >> > 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
next prev parent reply other threads:[~2012-05-09 3:12 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-17 8:35 [RFC 0/2] raid5 trim support Shaohua Li
2012-04-17 8:35 ` [RFC 1/2] MD: " Shaohua Li
2012-04-17 14:46 ` Dan Williams
2012-04-17 15:07 ` Shaohua Li
2012-04-17 18:16 ` Dan Williams
2012-04-17 20:26 ` NeilBrown
2012-04-18 0:58 ` Shaohua Li
2012-04-18 4:48 ` NeilBrown
2012-04-18 5:30 ` Shaohua Li
2012-04-18 5:57 ` NeilBrown
2012-04-18 6:34 ` Shaohua Li
2012-04-25 3:43 ` Shaohua Li
2012-05-08 10:16 ` Shaohua Li
2012-05-08 15:52 ` Dan Williams
2012-05-09 3:12 ` Shaohua Li [this message]
2012-05-08 20:17 ` NeilBrown
2012-04-17 8:35 ` [RFC 2/2] MD: raid5 avoid unnecessary zero page for trim Shaohua Li
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120509031232.GA507@kernel.org \
--to=shli@kernel.org \
--cc=axboe@kernel.dk \
--cc=dan.j.williams@intel.com \
--cc=linux-raid@vger.kernel.org \
--cc=neilb@suse.de \
--cc=shli@fusionio.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).