Received: by 2002:a05:6a10:6006:0:0:0:0 with SMTP id w6csp554999pxa; Thu, 27 Aug 2020 09:18:29 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyXAvWdnLmwqiEhmBSKxoVvctOo4WD+HqIfBStTc8MhZD+cl9iG87qN7Qwjdkxpvhlf9k5A X-Received: by 2002:a17:906:fa15:: with SMTP id lo21mr22642570ejb.42.1598545109619; Thu, 27 Aug 2020 09:18:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598545109; cv=none; d=google.com; s=arc-20160816; b=xLS11GFeozo7HfMOA/dVlU6T8HX89x6i6qlFG8xbIyZgpZ8gbD2ABahuEGh8ltPzUt umX50QCP0QJse8vEIees/3QhEx8oWCH5WuUtCyoTTEWNz4P3/P8zs42d9WE/6xZGAdeN Fl0LEexZWoaK7yFNtnq5+6j06ofgaQdoJokjaoB63+orCxWCZfx6yg6Zm71V7LCOqcaZ R70GyoAX2UTEev+8Cu8DOUlt2VsNYH0VA25AhVZz+rlFMhYBuxlLTrHBDjLji5mPsHG6 0SHcFxYa6IGCwLowUAOvEIsEdMZmnrE8CC0cbkSUp6/4qpr1/7YoprB5G/SgptkcCsom 8MJw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=e1CYi8h9cIcfFWE3IwWVVfAtEnrhdJEfYw9kxMmTqF4=; b=U09TeKQ+E7NNWkoEuP3PVTyVOSrCvCfFf8jD6bW+oo4ERC0y+SPZPpIAc/4U9xDbxj MWht7sIde+g7YLhjwHva6D6mGTKxG8akDmyEm79xpmleqGL8VPmkibJNBzk5dAaQ3RiU ixad9A6S5ys+69JTzWaUwk4e2TvR7zk/JKFbJiXu4FOJD9JxY4J08+cqcqpcObV2idK7 71/Pjk6H1M8HZVq1mSOsKMJOm7o85JV9++yz6j+x6uXxN3hU0K988taBzU2pUwO8sJOS HYQHNtgY/j9XoSQE5DiE3lfHZEex8IvVUrd8FgVTS/7gR766vQ1HIpxlfRUbO0lnHO6n zZag== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=Ugyty4oM; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b5si1783578eds.24.2020.08.27.09.18.06; Thu, 27 Aug 2020 09:18:29 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=Ugyty4oM; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727115AbgH0QO6 (ORCPT + 99 others); Thu, 27 Aug 2020 12:14:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46414 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726395AbgH0QO5 (ORCPT ); Thu, 27 Aug 2020 12:14:57 -0400 Received: from merlin.infradead.org (merlin.infradead.org [IPv6:2001:8b0:10b:1231::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2ED71C061264; Thu, 27 Aug 2020 09:14:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description; bh=e1CYi8h9cIcfFWE3IwWVVfAtEnrhdJEfYw9kxMmTqF4=; b=Ugyty4oMVrd/CQtmGftGd1GHb6 aP9yz/7iv/vaDj3FW7ESNBCoYx3laUXuM5AV4erwj+OZQgdgnvrxa4PH8Hd2gXf/dCOSAoyNZ9WPu qRocjg9sCU/zF9nu5tx3vdHkPguoaS7u4wydF6xrUa3c75EDHa2FnOf0Yq6y22FjAWqpCM/j7PPCa bzB/ajdtu2nm89fAAAmawCjU0nvX4B/9d3GSeNBXn1cJMVKmwW9qfeBkoKcy9uSNwkPa2N593nl+x yWBm54w+j6VI/3ly+oNqHEYAYBAClr7AMdK1415pinIZnuatzQhubdkey/nZQBTQkzOR+r3xc4ZKQ 8tWI8ghA==; Received: from [2601:1c0:6280:3f0::19c2] by merlin.infradead.org with esmtpsa (Exim 4.92.3 #3 (Red Hat Linux)) id 1kBKYA-0003Lq-Ca; Thu, 27 Aug 2020 16:14:54 +0000 Subject: Re: [PATCH v2] null_blk: add support for max open/active zone limit for zoned devices To: Damien Le Moal , Niklas Cassel , Jens Axboe Cc: Johannes Thumshirn , "linux-block@vger.kernel.org" , "linux-kernel@vger.kernel.org" References: <20200827135018.63644-1-niklas.cassel@wdc.com> <6d9fb163-f9d9-1f2d-d88c-db9d3a6185b4@infradead.org> From: Randy Dunlap Message-ID: <068d4bad-6061-277d-48d3-82a907f8c4a2@infradead.org> Date: Thu, 27 Aug 2020 09:14:50 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 8/27/20 8:04 AM, Damien Le Moal wrote: > On 2020/08/27 23:51, Randy Dunlap wrote: >> On 8/27/20 6:50 AM, Niklas Cassel wrote: >>> Add support for user space to set a max open zone and a max active zone >>> limit via configfs. By default, the default values are 0 == no limit. >> >> Hi, >> >> How does a user find out about how to use/set these limits? > > For the setting part, this is for testing. So any value, even extreme ones (e.g. > 1) would be OK to check that a software correctly handles write accesses to > zones for a device that has open/active zone limitations. A more practical way > is to reuse values of real devices. For instance, some SMR disks I use have a > max open limit of 128 and max active 0 (there is no limit for active zones on > SMR disks as ZBC/ZAC specifications do not define this concept). > > Another example is our soon to come work on btrfs zone support which shows that > at the very least 6 active zones are needed. So tests can be performed with that > minimum to check the file system and that its block allocator does not go > opening/activating too many zones. > > For the using part, the above btrfs example is good: if the FS tries to allocate > blocks in too many inactive zones at the same time without first filling out > zones already active, it may exceed the limit and writes will fail. The FS must > thus be aware of the limits and its block al;locator tuned to limit block > allocations within a set of zones smaller than the maximum active limit. > > Does this answer your question ? Yes. Thank you. -- ~Randy