From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8A54AC433F5 for ; Mon, 7 Mar 2022 16:36:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243903AbiCGQhd (ORCPT ); Mon, 7 Mar 2022 11:37:33 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35580 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233085AbiCGQhc (ORCPT ); Mon, 7 Mar 2022 11:37:32 -0500 Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:e::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9C5CC8A6E8; Mon, 7 Mar 2022 08:36:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=yTXlmVhXdue+hw7f3NKXFRnCD1J0MzuR7RUoJXiWM7g=; b=olmpuDa+nZWk/tfWvBDceZMqN3 AdZ3sJ/DL5xye0kqv7f6MzOhYgKKWywgGLOEh0HmsagJWoBsiQEezciTNfAsT11/6Nndh7wZr845G Y1sYyvPd3wnJ3fOjgXVnzpT6O3xW2p2igvzwtKCa/GBbsUol8l3k60vVj24pXMDDngHh/Ymj42RYx 4GubAboDiV4kG4oqrvyazJWOiboaXGWrJN6i9bvf7Sd2K/s6VNlLACyemTBCgwnQ7F/lTWVP136j9 PcxfpyrYfx9QUnUkksScXxYbEFVUUtobcVRA24yn2MdL6vkNNsCySLh7IY+L24IJdt+boO3FOQCGG DFL4Cnzg==; Received: from mcgrof by bombadil.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1nRGLb-000rHT-WF; Mon, 07 Mar 2022 16:36:36 +0000 Date: Mon, 7 Mar 2022 08:36:35 -0800 From: Luis Chamberlain To: Johannes Thumshirn Cc: Damien Le Moal , Dave Chinner , "linux-block@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , "lsf-pc@lists.linux-foundation.org" , Matias =?iso-8859-1?Q?Bj=F8rling?= , Javier =?iso-8859-1?Q?Gonz=E1lez?= , Damien Le Moal , Bart Van Assche , Adam Manzanares , Keith Busch , Naohiro Aota , Pankaj Raghav , Kanchan Joshi , Nitesh Shetty Subject: Re: [LSF/MM/BPF BoF] BoF for Zoned Storage Message-ID: References: <20220304001022.GJ3927073@dread.disaster.area> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: Luis Chamberlain Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Mon, Mar 07, 2022 at 04:23:46PM +0000, Johannes Thumshirn wrote: > On 07/03/2022 16:44, Luis Chamberlain wrote: > > On Mon, Mar 07, 2022 at 08:56:30AM +0900, Damien Le Moal wrote: > >> btrfs maps zones to block groups and the sectors between zone capacity > >> and zone size are marked as unusable. The report above is not showing > >> that. The coding is correct though. The block allocation will not be > >> attempted beyond zone capacity. > > > > That does not explain or justify why zone size was used instead of zone > > capacity. Using the zones size gives an incorrect inflated sense of actual > > capacity, and users / userspace applications can easily missuse that. > > > > Should other filesystems follow this logic as well? If so why? > > > > The justification is, when btrfs zoned support was implemented there was no > zone capacity. This started with zns and thus btrfs' knowledge of > zone_capacity came with it's zns support. So instead of playing the blame > game for whatever reason I don't want to know, you could have reported the > bug or fixed it yourself. I didn't realize it would be acknowledged as a bug, now that it is I'll just go send a fix, thanks! Luis