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 EE315C77B61 for ; Mon, 24 Apr 2023 19:05:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230340AbjDXTFY (ORCPT ); Mon, 24 Apr 2023 15:05:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56340 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229688AbjDXTFY (ORCPT ); Mon, 24 Apr 2023 15:05:24 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 652416591 for ; Mon, 24 Apr 2023 12:05:23 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id EC43F61B66 for ; Mon, 24 Apr 2023 19:05:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0F639C433D2; Mon, 24 Apr 2023 19:05:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1682363122; bh=S5lQ2lP2pHXYwHneghq1hwaCoIFl2gLHOyR7vMW0Akc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=V24ZfGQ4EmPgRei+4QJRAZDk/0RqeXOIRRc9O5NDNWC4/ffEB7woNo+vi2AdOmz61 bcdd78otCMK3WQ4sfByI5slsOUSb2jn+6voMurdDulJPDofXJDrL0s0FDV9bv1Ajfu FrU8fSqsd9wrFlOs57Apj+W+/SV0vd8tmDYC2UhAPp+NLggIMe/ySMr3+JDRAlgyvz FA+iLcqrrHgjErHJuG+pU1MN6laRk3a+NmQJpHg9v/qAyZEDr5GD0LxdyW+uG/rHxl ty7/VZfNPqvRzxwSMB3UvmdTNZZ3qK3ukH1XbVIhE+1g7dmjhQpmZ3R3NpRjvsewDM H8cGen6SYkRDA== Date: Mon, 24 Apr 2023 12:05:20 -0700 From: Jaegeuk Kim To: Christoph Hellwig Cc: Damien Le Moal , Bart Van Assche , Niklas Cassel , Jens Axboe , linux-block@vger.kernel.org, Ming Lei , Matias Bjorling Subject: Re: [PATCH v2 10/11] block: Add support for the zone capacity concept Message-ID: References: <141aee35-4288-1670-6424-e6c41c8ef4c9@kernel.org> <490ed061-6d82-f9fb-2050-4a386e2e4c8e@acm.org> <335b63b0-5a9e-472d-2cce-c0158ae93cf3@kernel.org> <20230424060139.GA9805@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230424060139.GA9805@lst.de> Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org On 04/24, Christoph Hellwig wrote: > On Sat, Apr 22, 2023 at 07:25:33AM +0900, Damien Le Moal wrote: > > >> for allocating blocks. This is a resource management issue. > > > > > > Ok, so it seems I overlooked there might be something in the zone allocation > > > policy. So, f2fs already manages 6 open zones by design. > > > > Yes, so as long as the device allows for at least 6 active zones, there are no > > issues with f2fs. > > I don't think it's quite as rosy, because f2fs can still schedule > I/O to the old zone after already scheduling I/O to a new zone for > any of these 6 slots. It'll need code to wait for all I/O to the old > zone to finish first, similar to btrfs. Hmm, I was concerned on the small zone size impacting the bandwidth, but feel that I can reduce the # of logs in F2FS in that case. So there's some trade-off. Let me take another look at, if I'm missing anything else. :(