Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp6717753yba; Wed, 1 May 2019 18:53:32 -0700 (PDT) X-Google-Smtp-Source: APXvYqxzYoYcgzuiO/83eB3qSBrsDSjOwnVwshDarvY3Oy+0a8BtN/ky+GMQ2F63H5jRdqP1HAus X-Received: by 2002:a65:4144:: with SMTP id x4mr1185255pgp.282.1556762012077; Wed, 01 May 2019 18:53:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556762012; cv=none; d=google.com; s=arc-20160816; b=M/TNssVuUAv5RR/nkte6l7uNudBPXxvGVMjggb1MQWK4NgKFqRv4poLnKj2PCHsZNR 6qLFX54ROT/JyWxuQaGszW7hOTdamjYjSS31xce/M8gpp8eclGZVRX85Wgw5gV6NfqqF VF8kQtUAqzsjacFBGGcQr44cx5ZgsCfw4Cn4SwQ4IbvFE5khIowb4bvVaYhVgTJSbgIC JQl1J/NCFz4Qt1vGBZlAwf+jOUn/XHSVzPQ+/uIQanOee4vuwuVh0/Ze+3RwMxKiUr17 iV19fM+Lfp9Dv0MfXqSx9fVnSKaFY4as4gaGRZWnXYYpZuQG8mVF2RQDAxmJvYkAYYCz cAPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=xNjOP9gg2QMy4x3ICBZoOoeoO4NbjsoS8XWQ33F0y5I=; b=cdwCzJrHQBAY+qH2j/VO6Q9b0qKMtTBXkh5Dj38oDIC231MzjKzjnU+4Qq51rI2qEn FfogOsXFkQ91fDJhQ2FwYQlnsxuUZKCsShZf+apkui6ss0tQsjgoVd9m5NV4p6GZEZOh NP/6TzjvMzFswUhIEbwMIpJqiUJp0TjI22ocja0RzbmyQG1wYEkrcCtj8otcEPOQufxw 98EcYrGFyr5CfbIWgJaOF1hbwUlUp7WeIBFZCm29n4r3BvfRyNwm9gGoeQPHAKbk1RB9 HTg6OnoKUE97GrJkcITDVQ7PJkIQKKnYPr3iqS0VEB5AjC1RZUNKK532zUrwNpO6OVvU Gs2Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=e1Cdnr7M; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g12si43331013plp.340.2019.05.01.18.53.13; Wed, 01 May 2019 18:53:32 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=e1Cdnr7M; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726245AbfEBBwR (ORCPT + 99 others); Wed, 1 May 2019 21:52:17 -0400 Received: from bombadil.infradead.org ([198.137.202.133]:44398 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726152AbfEBBwR (ORCPT ); Wed, 1 May 2019 21:52:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=xNjOP9gg2QMy4x3ICBZoOoeoO4NbjsoS8XWQ33F0y5I=; b=e1Cdnr7Mt+nZArvTOHcIt/dcH Ie+TXMWhFAYA5HNxT+y63lHRcgthMLNLL/PSs84r2uhvCLp73HMv7fZ+6i58oeYNTdQzpVsYqdBF3 nSsIM/r501mqjtAIkshkaSAWXLi3+lfbyh811CpB3RgxxHaVYJa6loRHloXhQ1iJ/dbbmb3AJHj1t pj+KBXXwUGZS7zTl5dGTlNJJTY1q4Id6eY+DUeLIZg2fShSdrsNHDR9dS/jmOXHnDsJZoKQLz3Qn1 j4DV7gXZmiWBaXasQ1mnVROZhkNd7/lbqMTeCiyj5EpOonGLtzfwRwoMya+eznp6sO5aOwOgMiYnW PWVOs2XIQ==; Received: from willy by bombadil.infradead.org with local (Exim 4.90_1 #2 (Red Hat Linux)) id 1hM0tT-0005DI-4W; Thu, 02 May 2019 01:52:15 +0000 Date: Wed, 1 May 2019 18:52:14 -0700 From: Matthew Wilcox To: Jerome Glisse Cc: Dave Chinner , lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [LSF/MM TOPIC] Direct block mapping through fs for device Message-ID: <20190502015214.GB8099@bombadil.infradead.org> References: <20190426013814.GB3350@redhat.com> <20190426062816.GG1454@dread.disaster.area> <20190426152044.GB13360@redhat.com> <20190427012516.GH1454@dread.disaster.area> <20190429132643.GB3036@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190429132643.GB3036@redhat.com> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 29, 2019 at 09:26:45AM -0400, Jerome Glisse wrote: > This is a filesystem opt-in feature if a given filesystem do not want > to implement it then just do not implement it and it will use page > cache. It is not mandatory i am not forcing anyone. The first reasons > for those are not filesystem but mmap of device file. But as LSF/MM > is up i thought it would be a good time to maybe propose that for file- > system too. If you do not want that for your filesystem then just NAK > any patch that add that to filesystem you care about. No. This is stupid, broken, and wrong. I know we already have application-visible differences between filesystems, and every single one of those is a bug. They may be hard bugs to fix, they may be bugs that we feel like we can't fix, they may never be fixed. But they are all bugs. Applications should be able to work on any Linux filesystem without having to care what it is. Code has a tendency to far outlive its authors expectations (and indeed sometimes its authors). If 'tar' had an #ifdef XFS / #elsif EXT4 / #elsif BTRFS / ... #endif, that would be awful. We need the same semantics across all major filesystems. Anything else is us making application developers lives harder than necessary, and that's unacceptable.