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 1C97FC433EF for ; Mon, 20 Jun 2022 17:38:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232421AbiFTRip (ORCPT ); Mon, 20 Jun 2022 13:38:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59654 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243607AbiFTRik (ORCPT ); Mon, 20 Jun 2022 13:38:40 -0400 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3E036764C for ; Mon, 20 Jun 2022 10:38:39 -0700 (PDT) Received: by verein.lst.de (Postfix, from userid 2407) id 3536D68AA6; Mon, 20 Jun 2022 19:38:35 +0200 (CEST) Date: Mon, 20 Jun 2022 19:38:34 +0200 From: Christoph Hellwig To: dsterba@suse.cz, Christoph Hellwig , David Sterba , Josef Bacik , Qu Wenruo , linux-btrfs@vger.kernel.org, Johannes Thumshirn Subject: Re: [PATCH 01/10] btrfs: remove a bunch of pointles stripe_len arguments Message-ID: <20220620173834.GA23580@lst.de> References: <20220617100414.1159680-1-hch@lst.de> <20220617100414.1159680-2-hch@lst.de> <20220620171608.GU20633@twin.jikos.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220620171608.GU20633@twin.jikos.cz> User-Agent: Mutt/1.5.17 (2007-11-01) Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org On Mon, Jun 20, 2022 at 07:16:08PM +0200, David Sterba wrote: > On Fri, Jun 17, 2022 at 12:04:05PM +0200, Christoph Hellwig wrote: > > The raid56 code assumes a fixed stripe length. > > The code does because it was part of the initial implementation but > raid56 as a feature wants a configurable stripe size, we have a super > block member for that. So the question is if passing the parameter is > such a burden so we'd rather remove it or keep it there though it's a > fixed value but still part of the design. > > I'd rather keep it there so it gets used eventually, we have ongoing > work to fix the corner cases of raid56 so removing and adding it back > causes churn, but I'll give it another thought. Well, right now it is very much dead code and complicates a lot of the argument passing as well as bloating the code size. IFF the superblock member were to be actually used in the future, it would make sense to expose it in the btrfs_fs_info and use that instead of the constant, but still skip all the argument passing. hch@brick:~/work/linux$ size btrfs.o.* text data bss dec hex filename 1502453 125590 28776 1656819 1947f3 btrfs.o.new 1502599 125590 28776 1656965 194885 btrfs.o.old