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.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_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 E5AA5C32751 for ; Wed, 7 Aug 2019 09:12:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B178221BE6 for ; Wed, 7 Aug 2019 09:12:39 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="cC8MgZv0" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727275AbfHGJMj (ORCPT ); Wed, 7 Aug 2019 05:12:39 -0400 Received: from mail-ed1-f52.google.com ([209.85.208.52]:36717 "EHLO mail-ed1-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726725AbfHGJMi (ORCPT ); Wed, 7 Aug 2019 05:12:38 -0400 Received: by mail-ed1-f52.google.com with SMTP id k21so85510540edq.3 for ; Wed, 07 Aug 2019 02:12:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=Nm/CVpS0exds9S1t4nWNC1vnmbGqdR6hZB4ZrhJrLSo=; b=cC8MgZv0NS3TrVVFDYZZQTTFor28vZGq0vVngR6ZxacVoNmwXtSZjnO5OGS5b/Svp3 Ji/E7VuoSjETjqVuE2h5szAHs5cYcFDmhL6vsAyVM0BajGduIhpA6phyZTGPJtsC9Yhg VYhMsLhU1/V1W0aUOSqQ9wLnp+emFioZ2ngArllSzMGDNuBP/N/ZNIjQllZqEuAxbPIm FzZFcnYYHzVaXgyWwoBFTZNsol1/uEnKUAolUUlR2L2t1SAMoUMbm49Nny7KF/ZREXVq izBf3Ix7MoVproMxcqWqk69ToUaxBD3CgD1YsS33yKEYIg1WqHVpLV5O31RritW4txqx MJMQ== 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=Nm/CVpS0exds9S1t4nWNC1vnmbGqdR6hZB4ZrhJrLSo=; b=bHJuaQNTNscOnGRAsWQeqcEJttakfpg4FgFgYUxEJ8GjUA38YHWqn8tWFtbSedHtFb FWRMve6WBofrmyzv/mKJ5PEk68Zg8tNmp3PkchAyDIzcJmzu2dHVh38ilfGKm2BMt0Hg gCrxl/4UcdrSCtDrI1yF7eb1VnNW7rEnoMPSOh6Pa6rKooGSElMLkRYHzeAGdwq1Jwpd LgoG6ZQq0oZiWbZ7HTQgpjItJ1GJqFqZG/GQGDZKpc+6qJeI5Yj1r99jtVOCaa3LI41x OEhBTjywJCbcYks4aBU55+4h+DgUMHAp8kmLI/xqzlc58VDqon6oHvi8tY8RsVHUOIqN xX/g== X-Gm-Message-State: APjAAAVxxA4LYmSHpghrZ3wbzNmlj9ZqPEbIajWKRRBBM+8GaFNuIyWr c49XdPiun9B6It730M80Rus= X-Google-Smtp-Source: APXvYqyM2zRX8PL/kFcM6MXS7vsInVEhpCP6DZAmJIaPJDSyxqd4Wr739fwV6r6VOycbMnxdI+Iwcw== X-Received: by 2002:a50:fb0a:: with SMTP id d10mr8294553edq.124.1565169157178; Wed, 07 Aug 2019 02:12:37 -0700 (PDT) Received: from GEERT-PC (82-217-81-70.cable.dynamic.v4.ziggo.nl. [82.217.81.70]) by smtp.gmail.com with ESMTPSA id k11sm20199041edq.54.2019.08.07.02.12.36 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Wed, 07 Aug 2019 02:12:36 -0700 (PDT) Date: Wed, 7 Aug 2019 11:12:34 +0200 From: Geert Custers To: Miklos Szeredi Cc: fuse-devel@lists.sourceforge.net, linux-fsdevel@vger.kernel.org Subject: Re: [fuse-devel] fuse zero copy Message-ID: <20190807091234.GA4907@GEERT-PC> References: <20190805101351.GB21755@GEERT-PC> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org > Actually it is being worked on. Attaching the current > proof-of-concept kernel patch for this. > > I don't have a patch for libfuse yet, as I'm testing new ideas with a > dummy filesystem that does raw /dev/fuse access. Also attached, needs > to be run with "-m" to enable the file mapping mode. I looked at the patch and proof of concept filesystem. I imagine the libfuse bindings would be relatively simple for this, something like a fuse_map_fd(), fuse_unmap_fd() and then a map() in the fuse_ops struct. > To make this more useful, the kernel would need to cache the mapping, > so it doesn't need to issue a MAP request on each read. That would > also optimize the case of long extents, or files mirrored completely > from an underlying filesystem (as done by the test program). I have some spare time so I could write some patches for libfuse and try add caching of the mapping on the kernel side. Maybe you can let me know your thoughts on what this would look like, so we are on the same page. Thanks, Geert