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=-3.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_NEOMUTT autolearn=ham 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 A117BC169C4 for ; Fri, 8 Feb 2019 10:36:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7800320857 for ; Fri, 8 Feb 2019 10:36:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726205AbfBHKgW (ORCPT ); Fri, 8 Feb 2019 05:36:22 -0500 Received: from mail-wm1-f65.google.com ([209.85.128.65]:40757 "EHLO mail-wm1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726022AbfBHKgW (ORCPT ); Fri, 8 Feb 2019 05:36:22 -0500 Received: by mail-wm1-f65.google.com with SMTP id q21so2836031wmc.5 for ; Fri, 08 Feb 2019 02:36:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=dnxuZ7w3T7NUpY26+4cKHRgS1wXMzdttktUyHnaA44Q=; b=ku3feH3yM1hIdmn9NAO8xX7FO9uPcyicBLIIdHVOz1/5ssfKiAJoAG665OzlntIaX6 qy5abU3JRvjiVzYYDeK6npgnZpFfa7ctPf50y4E4KLQXxoMqDgy8BKbu4zsbieSNzA5i LAjdIDFazcbfXLaFEt82qXuH83PM39EMZJjndeR60JGuPK0+DvsnUid6pmqlpeAEJuGE jQ5ml5+U8Fwx16nGAwmT2qU712SkDwQIgOH7SiYfHuVhFQ9sNaaJFlk7AhjGXQa9+TdD Lwlw0KHQGbfDZ0MtKV17JWvCgTvc/SajUX/0HafU6Su8ChnoQOhfdIQxPv+MePkIfjHo YRLQ== X-Gm-Message-State: AHQUAuajCUIQDq/Fh6t0eq8c2LSWqm4h0IJ76WHbceo6Ly8tuVYJKyHE /scRo2uK9vpt+0J0VlxCPXz6ww== X-Google-Smtp-Source: AHgI3IZgaHNnj/L5mqeVMLrtTcGg7m/G/gipnhPd5vxFohrTbx8xkvQ0q+ct70rtl4DBuzhjdDZj4g== X-Received: by 2002:a1c:f613:: with SMTP id w19mr11073895wmc.0.1549622179902; Fri, 08 Feb 2019 02:36:19 -0800 (PST) Received: from hades.usersys.redhat.com (ip-89-103-126-188.net.upcbroadband.cz. [89.103.126.188]) by smtp.gmail.com with ESMTPSA id r14sm1166107wrv.77.2019.02.08.02.36.18 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 08 Feb 2019 02:36:19 -0800 (PST) Date: Fri, 8 Feb 2019 11:36:17 +0100 From: Carlos Maiolino To: Christoph Hellwig Cc: Andreas Dilger , "Darrick J. Wong" , linux-fsdevel , Eric Sandeen , david@fromorbit.com Subject: Re: [PATCH 09/10 V2] Use FIEMAP for FIBMAP calls Message-ID: <20190208103617.dlhbal7xwglgujdu@hades.usersys.redhat.com> References: <20181205091728.29903-10-cmaiolino@redhat.com> <20181205173650.GA8112@magnolia> <20190204151147.rra4n7k56ec4ndob@hades.usersys.redhat.com> <20190204182722.GA32119@magnolia> <20190206133753.oqpw7citye6apdpr@hades.usersys.redhat.com> <20190206204431.GB32119@magnolia> <20190207115954.jfkf4fcoyfxqjue6@hades.usersys.redhat.com> <20190207170210.GB27972@magnolia> <20190208084612.GB23194@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190208084612.GB23194@lst.de> User-Agent: NeoMutt/20180716 Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Fri, Feb 08, 2019 at 09:46:12AM +0100, Christoph Hellwig wrote: > On Thu, Feb 07, 2019 at 02:25:01PM -0700, Andreas Dilger wrote: > > Do we really need to be this way, about reserving a single flag for Lustre, > > which will likely also be useful for other filesystems? It's not like > > Lustre is some closed-source binary module for which we need to make life > > difficult, it is used by many thousands of the largest computers at labs > > and universities and companies around the world. We are working to clean > > up the code outside the staging tree and resubmit it. Not reserving a flag > > just means we will continue to use random values in Lustre before it can > > be merged, which will make life harder when we try to merge again. > > No, it is available in source, but otherwise just as bad. And we generally > only define APIs for in-kernel usage. > > If we can come up with a good API for in-kernel filesystems we can do > that, otherwise hell no. And staging for that matter qualifies as out > of tree. > > That being said I'm really worried about these FIEMAP extensions as > userspace has no business poking into details of the placement (vs > just the layout). > I tend to say that identifying on which device an extent is is better than simply saying 'it maps to physical blocks X-Z, but it's your problem to identify which device X-Z belongs to'. > But all that belongs into a separate dicussion instead of dragging down > this series where it does not belong at all. Agreed, but now I'm on a kind of dead-end :P Darrick's concerns are valid, regarding letting currently unsupported filesystems to suddenly allow FIBMAP calls, but on the other hand, his proposed solution, which is also valid, requires a new discussion/patchset to discuss an improvement of the FIEMAP infra-structure, and 'fix' the problem mentioned. Using a flag to identify FIBMAP calls has been rejected. So, I'd accept suggestions on how to move this patch forward, without requiring the improvements suggested by Darrick, and, without using a flag to tag FIBMAP calls, as suggested by me, I'm kind of running out of ideas by now :( Cheers -- Carlos