From: Shaohua Li <shli@fb.com>
To: Christoph Hellwig <hch@lst.de>
Cc: neilb@suse.de, linux-raid@vger.kernel.org, Kernel-team@fb.com,
dan.j.williams@intel.com, Tejun Heo <tj@kernel.org>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
linux-ide@vger.kernel.org
Subject: Re: raid5-cache I/O path improvements
Date: Tue, 8 Sep 2015 09:56:22 -0700 [thread overview]
Message-ID: <20150908165611.GA371379@devbig257.prn2.facebook.com> (raw)
In-Reply-To: <20150908061215.GA23833@lst.de>
On Tue, Sep 08, 2015 at 08:12:15AM +0200, Christoph Hellwig wrote:
> On Mon, Sep 07, 2015 at 05:28:55PM -0700, Shaohua Li wrote:
> > Hi Christoph,
> > Thanks for these work. Yes, I/O error handling is in the plan. We could
> > simplify panic (people here like this option) or report error and bypass
> > log. Any way an option is good.
>
> I think the sensible thing in general is to fail the I/O. Once we have
> a cache devie the assumption is that a) write holes are properly handled,
> and we b) do all kinds of optimizations based on the presensce of the
> log device like not passing through flush requests or skippign resync.
>
> Having the cache device suddenly disappear will alwasy break a) and
> require a lot of hairy code only used in failure cases to undo the
> rest.
Failing the I/O is ok too.
> > For the patches, FUA write does simplify things a lot. However, I tried
> > it before, the performance is quite bad in SSD. FUA is off in SATA by
> > default, the emulation is farily slow because FLUSH request isn't NCQ
> > command. I tried to enable FUA in SATA too, FUA write is still slow in
> > the SSD I tested. Other than this one, other patches look good:
>
> Pretty much every SSD (and modern disk driver) supports FUA. Please
> benchmark with libata.fua=Y, as I think the simplifcation is absolutely
> worth it. On my SSDs using it gives far lower latency for writes,
> nevermind nvmdimm where it's also essential as the flush statemchine
> increases the write latency by an order of magnitude.
>
> Tejun, do you have any updates on libata vs FUA? We onable it
> by default for a while in 2012, but then Jeff reverted it with a rather
> non-descriptive commit message.
>
> Also NVMe or SAS SSDs will benefit heavily from the FUA bit.
I agree the benefit of FUA. In the system I'm testing, an Intel ssd
supports FUA, a sandisk SSD doesn't support FUA (this is the SSD we will
deploy for the log). This is AHCI with libata.fua=1. FUA isn't supported
by every SSD. If the log uses FUA by default, we will have a lot of FUA
write and performance is impacted.
I'll benchmark on a SSD from another vendor, which supports FUA, but FUA
write has poor performance in my last test.
Thanks,
Shaohua
next prev parent reply other threads:[~2015-09-08 16:56 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-07 5:20 raid5-cache I/O path improvements Christoph Hellwig
2015-09-07 5:20 ` [PATCH 01/10] raid5-cache: port to 4.3-rc Christoph Hellwig
2015-09-07 5:20 ` [PATCH 02/10] raid5-cache: free I/O units earlier Christoph Hellwig
2015-09-07 5:20 ` [PATCH 03/10] raid5-cache: use FUA writes for the log Christoph Hellwig
2015-09-07 5:20 ` [PATCH 04/10] raid5-cache: clean up r5l_get_meta Christoph Hellwig
2015-09-07 5:20 ` [PATCH 05/10] raid5-cache: refactor bio allocation Christoph Hellwig
2015-09-07 5:20 ` [PATCH 06/10] raid5-cache: take rdev->data_offset into account early on Christoph Hellwig
2015-09-07 5:20 ` [PATCH 07/10] raid5-cache: inline r5l_alloc_io_unit into r5l_new_meta Christoph Hellwig
2015-09-07 5:20 ` [PATCH 08/10] raid5-cache: new helper: r5_reserve_log_entry Christoph Hellwig
2015-09-07 5:20 ` [PATCH 09/10] raid5-cache: small log->seq cleanup Christoph Hellwig
2015-09-07 5:20 ` [PATCH 10/10] raid5-cache: use bio chaining Christoph Hellwig
2015-09-08 0:28 ` raid5-cache I/O path improvements Shaohua Li
2015-09-08 6:12 ` Christoph Hellwig
2015-09-08 15:25 ` Tejun Heo
2015-09-08 15:26 ` Tejun Heo
2015-09-08 15:40 ` Christoph Hellwig
2015-09-08 16:56 ` Shaohua Li [this message]
2015-09-08 17:02 ` Tejun Heo
2015-09-08 17:07 ` Shaohua Li
2015-09-08 17:34 ` Tejun Heo
2015-09-09 15:59 ` Christoph Hellwig
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=20150908165611.GA371379@devbig257.prn2.facebook.com \
--to=shli@fb.com \
--cc=Kernel-team@fb.com \
--cc=dan.j.williams@intel.com \
--cc=hch@lst.de \
--cc=linux-ide@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=neilb@suse.de \
--cc=tj@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.