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!
next prev parent 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).