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=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED 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 E5958C43387 for ; Mon, 14 Jan 2019 17:56:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A81342086D for ; Mon, 14 Jan 2019 17:56:29 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="fKZnHTj6" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726744AbfANR43 (ORCPT ); Mon, 14 Jan 2019 12:56:29 -0500 Received: from mail-it1-f196.google.com ([209.85.166.196]:38385 "EHLO mail-it1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726732AbfANR42 (ORCPT ); Mon, 14 Jan 2019 12:56:28 -0500 Received: by mail-it1-f196.google.com with SMTP id h65so648296ith.3 for ; Mon, 14 Jan 2019 09:56:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=+rcS4sq8IItVIgVjEMZWNUFurA3UATgEwuXyc3fMFWQ=; b=fKZnHTj6cMzNSG5fL2fCnqLy0/fcBuXQBS17KVug3xCsmiDqqwJRc706Ng6a8ERZ4O me7/qS5RxTgunKtq5mz1bO2kAvYrYHnBubDeQeCcGLRwIA73P7GhsinP6faAaa1xrEyb QLjUezF0XW1t46Rwd0F5dCp+5wYgxBn2IWMfFOuP6Am7APyfeDPMfY4ra2d0Y5Bfj5gd NgSVmAgAQZ1gQNMIgLGvxM4FlPdcPKM6fTqfYGPlYRIYsW9W5/qbj7Yh7x/HdIEsPQE3 U/AOUwOuW3Uyt1gsMtqEeuGlX569nsKKCs13NxTxtD8+t9w/pQIKy1xNIHleFNDyPmaR cgBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=+rcS4sq8IItVIgVjEMZWNUFurA3UATgEwuXyc3fMFWQ=; b=Sm4+hF6L8uHXSJT634EpDm3+uYjmBieO1GBwu5/GHAff8sZ4eakLSGeHNTiFSUDsE4 oJtzsUP70p+E3Ad2KS/mBEwgjOosZ+KIL2F62BekNqmR9tTBGzjs/OuoHkWa85MhQbK6 senQOPuyMCUfNKjb8YtDzStibYKUE3LuXPS3QpVEFkROLxkLUDUcKMU43+/JIMkv8acm NW2EhvlJ4yi3wgikjMEMWk5OcU8r+9WJe8yAfs/GTSriKWIgwy8gx79TPipmBW+ubja0 h+GFRprku3klJI8e9uTQJItEfrH8MuYgE8U3T7C2MrsBtXCvl606zcrntiUOCilizJ2l F8tw== X-Gm-Message-State: AJcUukfl/A23KTPgsrpJkzVPI+9mbo36SwGvUnJOLVpy23qOZx2uV6uV aNsAhxOvinmk22RzzXOXRZW7J9pUNuYu87mjEbg= X-Google-Smtp-Source: ALg8bN6uSLaljv2MjyB6+LmDgqCkbnT6+Zb3Mv38wooy+7ZDvsTxD/HS9zXo4eZ3sRUpP2GElHhTsRplUCAl6A6eb+0= X-Received: by 2002:a24:2912:: with SMTP id p18mr233741itp.16.1547488587633; Mon, 14 Jan 2019 09:56:27 -0800 (PST) MIME-Version: 1.0 References: <20181205091728.29903-1-cmaiolino@redhat.com> <20181207093429.t3zzkxmfc4wlt5ny@hades.usersys.redhat.com> <20190114165023.GB7187@lst.de> In-Reply-To: <20190114165023.GB7187@lst.de> From: =?UTF-8?Q?Andreas_Gr=C3=BCnbacher?= Date: Mon, 14 Jan 2019 18:56:16 +0100 Message-ID: Subject: Re: [PATCH 00/10 V2] New ->fiemap infrastructure and ->bmap removal To: Christoph Hellwig Cc: Carlos Maiolino , Linux FS-devel Mailing List , Andreas Dilger , sandeen@redhat.com, Dave Chinner Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org Am Mo., 14. Jan. 2019 um 17:50 Uhr schrieb Christoph Hellwig : > On Fri, Dec 07, 2018 at 10:34:29AM +0100, Carlos Maiolino wrote: > > On Thu, Dec 06, 2018 at 07:56:02PM +0100, Andreas Gr=C3=BCnbacher wrote= : > > > Hi, > > > > > > Am Mi., 5. Dez. 2018 um 10:18 Uhr schrieb Carlos Maiolino > > > : > > > > This is the second version of the complete series with the goal to = remove ->bmap > > > > interface completely, in lieu of FIEMAP. > > > > > > I'm not thrilled by this approach. How about exposing the iomap > > > operations at the vfs layer (for example, in the super block) and > > > implementing bmap on top of that instead? > > > > > > > Well, the idea is exactly to get rid of bmap, not reimplement it. We ca= n use the > > same operation for both cases (fiemap+fibmap), so I honestly don't see = which > > advantages would be by reimplementing it. > > Exactly. iomap really is a possibly implementation. Everytime we > exposed implementation details at the ops level that created horrible > abuses. The most important still relevant example is > write_begin/write_end, which require fs specific locking but are > exposed in a way where we can't easily enforce that. Yes, locking. The fiemap_fill_cb callback hack still makes the fiemap interface much uglier though. So couldn't the existing iop be used to fill a kernel buffer in a way similar to what functions like kernel_readv do? That would at least avoid wrecking an existing interface. Thanks, Andreas