From: Sagi Grimberg <sagi@grimberg.me>
To: David Woodhouse <dwmw2@infradead.org>, Keith Busch <kbusch@kernel.org>
Cc: Jens Axboe <axboe@fb.com>, James Smart <james.smart@broadcom.com>,
linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org,
Keith Busch <keith.busch@intel.com>,
Maximilian Heyne <mheyne@amazon.de>, Amit Shah <aams@amazon.de>,
Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH v2 0/2] Adding per-controller timeout support to nvme
Date: Wed, 24 Apr 2019 13:58:56 -0700 [thread overview]
Message-ID: <db034829-7140-1374-0132-7d27240b8b3b@grimberg.me> (raw)
In-Reply-To: <983e5d039dce9de1d32c71d28fd59bbc01c3fee5.camel@infradead.org>
>>>> As different nvme controllers are connect via different fabrics, some require
>>>> different timeout settings than others. This series implements per-controller
>>>> timeouts in the nvme subsystem which can be set via sysfs.
>>>
>>> How much of a real issue is this?
>>>
>>> block io_timeout defaults to 30 seconds which are considered a universal
>>> eternity for pretty much any nvme fabric. Moreover, io_timeout is
>>> mutable already on a per-namespace level.
>>>
>>> This leaves the admin_timeout which goes beyond this to 60 seconds...
>>>
>>> Can you describe what exactly are you trying to solve?
>>
>> I think they must have an nvme target that is backed by slow media
>> (i.e. non-SSD). If that's the case, I think it may be a better option
>> if the target advertises relatively shallow queue depths and/or lower
>> MDTS that better aligns to the backing storage capabilies.
>
> It isn't that the media is slow; the max timeout is based on the SLA
> for certain classes of "fabric" outages. Linux copes *really* badly
> with I/O errors, and if we can make the timeout last long enough to
> cover the switch restart worst case, then users are a lot happier.
Well, what is usually done to handle fabric outages is having multiple
paths to the storage device, not sure if that is applicable for you or
not...
What do you mean by "Linux copes *really* badly with I/O errors"? What
can be done better?
next prev parent reply other threads:[~2019-04-24 20:59 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-03 12:35 [PATCH v2 0/2] Adding per-controller timeout support to nvme Maximilian Heyne
2019-04-03 12:35 ` [PATCH v2 1/2] nvme: add per-controller io and admin timeouts Maximilian Heyne
2019-04-03 12:35 ` [PATCH v2 2/2] nvme: add sysfs controls for " Maximilian Heyne
2019-04-09 10:23 ` Christoph Hellwig
2019-04-24 16:55 ` [PATCH v2 0/2] Adding per-controller timeout support to nvme Sagi Grimberg
2019-04-24 20:07 ` Keith Busch
2019-04-24 20:30 ` David Woodhouse
2019-04-24 20:44 ` Keith Busch
2019-04-24 20:58 ` Sagi Grimberg [this message]
2019-04-25 5:45 ` David Woodhouse
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=db034829-7140-1374-0132-7d27240b8b3b@grimberg.me \
--to=sagi@grimberg.me \
--cc=aams@amazon.de \
--cc=axboe@fb.com \
--cc=dwmw2@infradead.org \
--cc=hch@lst.de \
--cc=james.smart@broadcom.com \
--cc=kbusch@kernel.org \
--cc=keith.busch@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=mheyne@amazon.de \
/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).