Linux-Block Archive on lore.kernel.org
 help / color / Atom feed
From: Damien Le Moal <Damien.LeMoal@wdc.com>
To: Coly Li <colyli@suse.de>,
	"linux-bcache@vger.kernel.org" <linux-bcache@vger.kernel.org>
Cc: Johannes Thumshirn <Johannes.Thumshirn@wdc.com>,
	"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
	"hare@suse.com" <hare@suse.com>
Subject: Re: [RFC PATCH v4 2/3] bcache: handle zone management bios for bcache device
Date: Wed, 3 Jun 2020 00:51:45 +0000
Message-ID: <CY4PR04MB375123D5B0E99781D1A3D319E7880@CY4PR04MB3751.namprd04.prod.outlook.com> (raw)
In-Reply-To: <e73f00de-f5d0-a8f7-e7a6-c3285fbfd368@suse.de>

On 2020/06/02 19:18, Coly Li wrote:
> On 2020/6/2 16:54, Damien Le Moal wrote:
>> On Tue, 2020-06-02 at 00:06 +0800, Coly Li wrote:
>>>>> +		 * cache device.
>>>>> +		 */
>>>>> +		if (bio_op(bio) == REQ_OP_ZONE_RESET_ALL)
>>>>> +			nr_zones = s->d->disk->queue->nr_zones;
>>>>
>>>> Not: sending a REQ_OP_ZONE_RESET BIO to a conventional zone will be failed by
>>>> the disk... This is not allowed by the ZBC/ZAC specs. So invalidation the cache
>>>> for conventional zones is not really necessary. But as an initial support, I
>>>> think this is fine. This can be optimized later.
>>>>
>>> Copied, will think of how to optimized later. So far in my testing,
>>> resetting conventional zones may receive error and timeout from
>>> underlying drivers and bcache code just forwards such error to upper
>>> layer. What I see is the reset command hangs for a quite long time and
>>> failed. I will find a way to make the zone reset command on conventional
>>> zone fail immediately.
>>
>> It is 100% guaranteed that a zone reset issued to a conventional zone
>> will fail. That is defined in ZBC/ZAC specifications. Resetting a
>> single conventional zone is an error. We know the command will fail and
>> the failure is instantaneous from the drive. The scsi layer should not
>> retry these failed reset zone command, we have special error handling
>> code preventing retries since we know that the command can only fail
>> again. So I am not sure why you are seeing hang/long time before the
>> failure is signaled... This may need investigation.
>>
>>
> 
> Copied. Currently I plan to add a first_seq_zone_nr to bcache on-disk
> super block, its value will be set by user space bcache-tools when the
> backing device is formatted for bcache. Then the zone reset bio which
> has smaller zone number will be rejected immediately by bcache code.
> 
> This requires on-disk format change, I will do it later with other
> on-disk change stuffs.

I do not think you actually need an on-disk format change for this since that
information can simply live in memory. Also, it is not entirely correct to
assume that all conventional zones are at LBA 0 onward up to the first
sequential zone. It just happens that this is what drives on the market look
like today, but the standard allows conventional zones to be anywhere in the
disk address space. The safe way to handle this is to do something like the
block layer does using a bitmap indicating if a zone is sequential or
conventional. Not that using the bitmap already attached to the device request
queue is possible but not safe since the backend device could be a DM target, so
a BIO device with a request queue that does not have zone bitmaps. So allocating
your own bitmap and doing a report zones to initialize it when the device is
started is safer and will give you something very solid with no on-disk format
change needed.

See fs/f2fs/super.c function init_blkz_info(), that is exactly what is done:
allocation and initialization of a bitmap to identify zone types.

> 
> Coly Li
> 


-- 
Damien Le Moal
Western Digital Research

  reply index

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-22 12:18 [RFC PATCH v4 0/3] bcache: support zoned device as bcache backing device Coly Li
2020-05-22 12:18 ` [RFC PATCH v4 1/3] bcache: export bcache zone information for zoned " Coly Li
2020-05-25  1:10   ` Damien Le Moal
2020-06-01 12:34     ` Coly Li
2020-06-02  8:48       ` Damien Le Moal
2020-06-02 12:50         ` Coly Li
2020-06-03  0:58           ` Damien Le Moal
2020-05-22 12:18 ` [RFC PATCH v4 2/3] bcache: handle zone management bios for bcache device Coly Li
2020-05-25  1:24   ` Damien Le Moal
2020-06-01 16:06     ` Coly Li
2020-06-02  8:54       ` Damien Le Moal
2020-06-02 10:18         ` Coly Li
2020-06-03  0:51           ` Damien Le Moal [this message]
2020-05-22 12:18 ` [RFC PATCH v4 3/3] bcache: reject writeback cache mode for zoned backing device Coly Li
2020-05-25  1:26   ` Damien Le Moal
2020-06-01 16:09     ` Coly Li
2020-05-25  5:25 ` [RFC PATCH v4 0/3] bcache: support zoned device as bcache " Damien Le Moal
2020-05-25  8:14   ` Coly Li

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=CY4PR04MB375123D5B0E99781D1A3D319E7880@CY4PR04MB3751.namprd04.prod.outlook.com \
    --to=damien.lemoal@wdc.com \
    --cc=Johannes.Thumshirn@wdc.com \
    --cc=colyli@suse.de \
    --cc=hare@suse.com \
    --cc=linux-bcache@vger.kernel.org \
    --cc=linux-block@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

Linux-Block Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-block/0 linux-block/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-block linux-block/ https://lore.kernel.org/linux-block \
		linux-block@vger.kernel.org
	public-inbox-index linux-block

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-block


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git