From: "Martin K. Petersen" <martin.petersen@oracle.com>
To: Shaun Tancheff <shaun@tancheff.com>
Cc: linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
"James E . J . Bottomley" <jejb@linux.vnet.ibm.com>,
"Martin K . Petersen" <martin.petersen@oracle.com>,
Josh Bingaman <josh.bingaman@seagate.com>,
Shaun Tancheff <shaun.tancheff@seagate.com>
Subject: Re: [PATCH] Update WRITE_SAME timeout in sd_setup_discard_cmnd
Date: Thu, 11 Aug 2016 22:08:33 -0400 [thread overview]
Message-ID: <yq1fuqapwm6.fsf@sermon.lab.mkp.net> (raw)
In-Reply-To: <1470946358-6744-1-git-send-email-shaun@tancheff.com> (Shaun Tancheff's message of "Thu, 11 Aug 2016 15:12:38 -0500")
>>>>> "Shaun" == Shaun Tancheff <shaun@tancheff.com> writes:
Shaun,
Shaun> In sd_setup_discard_cmnd() there are a some discard methods that
Shaun> fall back to using WRITE_SAME. It appears that those paths using
Shaun> WRITE_SAME should also use the SD_WRITE_SAME_TIMEOUT instead of
Shaun> the default SD_TIMEOUT.
The expectation is that the UNMAP variants update a translation table of
some sort in close to constant time. Potentially with some head and tail
zeroing on media. And should therefore easily fall within the 30s limit.
But you have a point wrt. SD_LBP_ZERO. It was used for one particular
type of array that did zero block detection (and thus didn't actually
write anything either). I don't think anybody is using this mode of
operation anymore since thin provisioning has been formalized in T10 for
quite a while. But I'd be OK with a patch that uses
SD_WRITE_SAME_TIMEOUT for that particular code path.
--
Martin K. Petersen Oracle Linux Engineering
prev parent reply other threads:[~2016-08-12 2:08 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-11 20:12 Shaun Tancheff
2016-08-12 2:08 ` Martin K. Petersen [this message]
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=yq1fuqapwm6.fsf@sermon.lab.mkp.net \
--to=martin.petersen@oracle.com \
--cc=jejb@linux.vnet.ibm.com \
--cc=josh.bingaman@seagate.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=shaun.tancheff@seagate.com \
--cc=shaun@tancheff.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
all inboxes | Powered by JetHome®