linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: majianpeng <majianpeng@gmail.com>
To: nab <nab@linux-iscsi.org>, Andy Grover <agrover@redhat.com>
Cc: linux-scsi <linux-scsi@vger.kernel.org>,
	target-devel <target-devel@vger.kernel.org>
Subject: Re: Re: [PATCH] target: For iblock at default writecache enable.
Date: Wed, 30 Jan 2013 09:19:16 +0800	[thread overview]
Message-ID: <201301300919014311109@gmail.com> (raw)
In-Reply-To: 1359501265.23290.1720.camel@haakon2.linux-iscsi.org

>On Tue, 2013-01-29 at 15:04 -0800, Andy Grover wrote:
>> On 01/29/2013 11:03 AM, Nicholas A. Bellinger wrote:
>> 
>> > So enabling emulate_write_cache=1 in the case when the underlying device
>> > has not enabled it is incorrect.
>> > 
>> > I'd like to enable this bit when we know the underlying device has WCE=1
>> > set, but currently there is not a way to determine this (generically)
>> > from struct block_device.
>> > 
>> > So NACK for applying this until there is a method to determine what the
>> > hardware below is doing.
>> 
>> This should be possible from userspace though. I'm planning on looking
>> up underlying scsi device(s?) using libblkid, and then query the sense
>> data using libsgutils when adding a block backstore in targetcli.
>> 
>
>Querying the mode pages from userspace would work for the SCSI backstore
>case, but certainly not for raw block devices.
>
>I'd still like to see this exposed to the block layer somehow, so that
>the setting can be automatically determined by TCM once it's known if
>the underlying HW has enabled write caching.
>
>> It's kind of a hassle, but isn't it a huge performance win if we can
>> enable this?
>> 
>
>Most certainly, but the danger is reporting WCE=1 (by default in all
>cases) from TCM to the initiator when the underlying drives do not have
>caching enabled.  Note that every spinning media device that I've ever
>seen disables WCE by default from the factory.
Sorry, what's the danger?Can you explain the details?
And for most sata hdd the WCE  is enable by default.
IMHO, for hard-raid the WCE will be disable, it used the cache of hardraid-card.

In func sd_revalidate_disk:
>	/*
>	 * We now have all cache related info, determine how we deal
>	 * with flush requests.
>	 */
>	if (sdkp->WCE) {
>		flush |= REQ_FLUSH;
>		if (sdkp->DPOFUA)
>			flush |= REQ_FUA;
>	}

>	blk_queue_flush(sdkp->disk->queue, flush);
We can use queue->flush_flags.
But in func generic_make_request_checks:
>/*
>	 * Filter flush bio's early so that make_request based
>	 * drivers without flush support don't have to worry
>	 * about them.
>	 */
>	if ((bio->bi_rw & (REQ_FLUSH | REQ_FUA)) && !q->flush_flags) {
>		bio->bi_rw &= ~(REQ_FLUSH | REQ_FUA);
So if uderlying device don't support WCE, it can remove REQ_FUA|REQ_FLUSH.
I think enable writecache by default is ok.

Jianpeng
Thanks!

  reply	other threads:[~2013-01-30  1:19 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-25  1:58 [PATCH] target: For iblock at default writecache enable majianpeng
2013-01-29 19:03 ` Nicholas A. Bellinger
2013-01-29 23:04   ` Andy Grover
2013-01-29 23:14     ` Nicholas A. Bellinger
2013-01-30  1:19       ` majianpeng [this message]
2013-01-30  7:29         ` Nicholas A. Bellinger

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=201301300919014311109@gmail.com \
    --to=majianpeng@gmail.com \
    --cc=agrover@redhat.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=nab@linux-iscsi.org \
    --cc=target-devel@vger.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 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).