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 X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 75B84C433E0 for ; Mon, 22 Feb 2021 16:03:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 382E564E74 for ; Mon, 22 Feb 2021 16:03:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231321AbhBVQDk (ORCPT ); Mon, 22 Feb 2021 11:03:40 -0500 Received: from mx2.suse.de ([195.135.220.15]:37994 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231253AbhBVQDb (ORCPT ); Mon, 22 Feb 2021 11:03:31 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 4CEC4AFBF; Mon, 22 Feb 2021 16:02:48 +0000 (UTC) Received: by ds.suse.cz (Postfix, from userid 10065) id 4C219DA7FF; Mon, 22 Feb 2021 17:00:49 +0100 (CET) Date: Mon, 22 Feb 2021 17:00:49 +0100 From: David Sterba To: Naohiro Aota Cc: dsterba@suse.cz, Johannes Thumshirn , "linux-btrfs@vger.kernel.org" , "dsterba@suse.com" , "hare@suse.com" , "linux-fsdevel@vger.kernel.org" , Damien Le Moal Subject: Re: [PATCH v15 00/42] btrfs: zoned block device support Message-ID: <20210222160049.GR1993@twin.jikos.cz> Reply-To: dsterba@suse.cz Mail-Followup-To: dsterba@suse.cz, Naohiro Aota , Johannes Thumshirn , "linux-btrfs@vger.kernel.org" , "dsterba@suse.com" , "hare@suse.com" , "linux-fsdevel@vger.kernel.org" , Damien Le Moal References: <20210210195829.GW1993@twin.jikos.cz> <20210211151901.GD1993@twin.jikos.cz> <20210211154627.GE1993@twin.jikos.cz> <20210216043247.cjxybi7dudpgvvyg@naota-xeon> <20210216114611.GM1993@suse.cz> <20210222075043.3g7watpx5gedguaj@naota-xeon> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210222075043.3g7watpx5gedguaj@naota-xeon> User-Agent: Mutt/1.5.23.1-rc1 (2014-03-12) Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org On Mon, Feb 22, 2021 at 04:50:43PM +0900, Naohiro Aota wrote: > > For real hardware I think this is not relevant but for the emulated mode > > we need to deal with that case. The reserved size is wasteful and this > > will become noticeable for devices < 16G but I'd rather keep the logic > > simple and not care much about this corner case. So, the superblock > > range would be reserved and if there's not enough to store the secondary > > sb, then don't. > > Sure. That works. I'm running xfstests with these new SB > locations. Once it passed, I'll post the patch. > > One corner case left. What should we do with zone size > 8G? In this > case, the primary SB zones and the 1st copy SB zones overlap. I know > this is unrealistic for real hardware, but you can still create such a > device with null_blk. > > 1) Use the following zones (zones #2, #3) as the primary SB zones > 2) Do not write the primary SBs > 3) Reject to mkfs > > To be simple logic, method #3 would be appropriate here? > > Technically, all the log zones overlap with zone size > 128 GB. I'm > considering to reject to mkfs in this insane case anyway. The 8G zone size idea is to buy us some time to support future hardware, once this won't suffice we'll add an incompat bit like BIGZONES that will allow larger zone sizes. At that time we'll probably have a better idea about an exact number. So it's #3.