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_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 C208FC606BD for ; Mon, 8 Jul 2019 16:03:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A484B21537 for ; Mon, 8 Jul 2019 16:03:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390893AbfGHQDy (ORCPT ); Mon, 8 Jul 2019 12:03:54 -0400 Received: from verein.lst.de ([213.95.11.211]:34715 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388273AbfGHQDy (ORCPT ); Mon, 8 Jul 2019 12:03:54 -0400 Received: by verein.lst.de (Postfix, from userid 2407) id 28724227A81; Mon, 8 Jul 2019 18:03:52 +0200 (CEST) Date: Mon, 8 Jul 2019 18:03:51 +0200 From: Christoph Hellwig To: Andreas Gruenbacher Cc: Christoph Hellwig , "Darrick J . Wong" , linux-xfs@vger.kernel.org, linux-fsdevel , cluster-devel Subject: Re: RFC: use the iomap writepage path in gfs2 Message-ID: <20190708160351.GA9871@lst.de> References: <20190701215439.19162-1-hch@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Thu, Jul 04, 2019 at 12:35:41AM +0200, Andreas Gruenbacher wrote: > Patch "gfs2: implement gfs2_block_zero_range using iomap_zero_range" > isn't quite ready: the gfs2 iomap operations don't handle IOMAP_ZERO > correctly so far, and that needs to be fixed first. What is the issue with IOMAP_ZERO on gfs2? Zeroing never does block allocations except when on COW extents, which gfs2 doesn't support, so there shouldn't really be any need for additional handling. > Some of the tests assume that the filesystem supports unwritten > extents, trusted xattrs, the usrquota / grpquota / prjquota mount > options. There shouldn't be a huge number of failing tests beyond > that, but I know things aren't perfect. In general xfstests is supposed to have tests for that and not run the tests if not supported. In most cases this is automatic, but in case a feature can't be autodetect we have a few manual overrides.