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.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT 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 BC8FCC169C4 for ; Fri, 8 Feb 2019 08:46:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 983B921919 for ; Fri, 8 Feb 2019 08:46:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727309AbfBHIqN (ORCPT ); Fri, 8 Feb 2019 03:46:13 -0500 Received: from verein.lst.de ([213.95.11.211]:41114 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726115AbfBHIqN (ORCPT ); Fri, 8 Feb 2019 03:46:13 -0500 Received: by newverein.lst.de (Postfix, from userid 2407) id 86E8968D93; Fri, 8 Feb 2019 09:46:12 +0100 (CET) Date: Fri, 8 Feb 2019 09:46:12 +0100 From: Christoph Hellwig To: Andreas Dilger Cc: "Darrick J. Wong" , Carlos Maiolino , linux-fsdevel , Christoph Hellwig , Eric Sandeen , david@fromorbit.com Subject: Re: [PATCH 09/10 V2] Use FIEMAP for FIBMAP calls Message-ID: <20190208084612.GB23194@lst.de> References: <20181205091728.29903-1-cmaiolino@redhat.com> <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> 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, 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). But all that belongs into a separate dicussion instead of dragging down this series where it does not belong at all.