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=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_MUTT autolearn=unavailable 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 D61E1C48BD5 for ; Tue, 25 Jun 2019 10:10:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B95A72168B for ; Tue, 25 Jun 2019 10:10:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727163AbfFYKKw (ORCPT ); Tue, 25 Jun 2019 06:10:52 -0400 Received: from verein.lst.de ([213.95.11.211]:33426 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726274AbfFYKKw (ORCPT ); Tue, 25 Jun 2019 06:10:52 -0400 Received: by newverein.lst.de (Postfix, from userid 2407) id D25E668B05; Tue, 25 Jun 2019 12:10:20 +0200 (CEST) Date: Tue, 25 Jun 2019 12:10:20 +0200 From: Christoph Hellwig To: Dave Chinner Cc: Christoph Hellwig , "Darrick J . Wong" , Damien Le Moal , Andreas Gruenbacher , linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 11/12] iomap: move the xfs writeback code to iomap.c Message-ID: <20190625101020.GI1462@lst.de> References: <20190624055253.31183-1-hch@lst.de> <20190624055253.31183-12-hch@lst.de> <20190624234304.GD7777@dread.disaster.area> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190624234304.GD7777@dread.disaster.area> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Tue, Jun 25, 2019 at 09:43:04AM +1000, Dave Chinner wrote: > I'm a little concerned this is going to limit what we can do > with the XFS IO path because now we can't change this code without > considering the direct impact on other filesystems. The QA burden of > changing the XFS writeback code goes through the roof with this > change (i.e. we can break multiple filesystems, not just XFS). Going through the roof is a little exaggerated. Yes, it will be more testing overhead, but that is life in a world where we try to share code rather than duplicating it, which is pretty much a general kernel policy that has served us well. > The writepage code is one of the areas that, historically speaking, > has one of the highest rates of modification in XFS - we've > substantially reworked this code from top to bottom 4 or 5 times in > a bit over ten years, and each time it's been removing abstraction > layers and getting the writeback code closer to the internal XFS > extent mapping infrastructure. I don't think we had all that much churn. Yes, we've improved it a lot, but much of that was in response to core changes, and pretty much all of it benefits other users as well. And the more users we have for this infrastructure that more clout it has with core VM folks when we have to push back odd design decisions.