All of lore.kernel.org
 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 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.