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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5ED02ECAAD5 for ; Mon, 12 Sep 2022 13:03:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229847AbiILNDt (ORCPT ); Mon, 12 Sep 2022 09:03:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44044 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229510AbiILNDr (ORCPT ); Mon, 12 Sep 2022 09:03:47 -0400 Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C59B922294 for ; Mon, 12 Sep 2022 06:03:45 -0700 (PDT) Received: by mail-ej1-x634.google.com with SMTP id r18so20007461eja.11 for ; Mon, 12 Sep 2022 06:03:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=szeredi.hu; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=gzeDS0G1ZIUKM4GYz7abbjxSlpxz2Mijey/kQuuMkfY=; b=CfIQzgzZCyVr9wlstJxLH+NrDFeHEXR+57tREBr4yZomgx5J01hdi8CNaswUAGNufB iIBvEmZsyMfvoabVa3UccxrPtjHVl7WSxqoEfDBIvdYOIpNdUBe9X8BMOGAkq4w056d4 LwS6KRA/VKPJKviNNBIC5IZJui/QpEDlBgHgE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=gzeDS0G1ZIUKM4GYz7abbjxSlpxz2Mijey/kQuuMkfY=; b=OIvIl3hlYL5mo+mmNJ54MsB/0JTUf3OsfErAOgb8z0AZ0H2YU3UGP+rcaESxsuL7rl O3Y1HJBpMHBPojverghvRHa1CKNinDnOW4v1AqGZoP70Fnh81Dn4k6T21tlwLGf+flCT 2ygNRsHS9jCmsJCWIrDCxIAIArAeiH2V0X7DTpA6Lgbr9goDU2yAUiTli0ZyIXLzHY6N I0J73nSBXWzNNMorGCC9aLEJSgwpWp0OGB0iw/Y+7NlGa4PjZv7hquZZioGUtHXz+AKL yPRs83BbjMW/Tg1gZLGOtTrL7ooMkPC38wN6S3A5owwesewz1Ypl4e4FKYNZVfWKAxcR f78g== X-Gm-Message-State: ACgBeo0MBJGbgLSRjADgp39wU4vPPDFQrLgP4E9ZyvA+VxUrRnW6P31J 8G6knsVyZPgnhZkUBxJ2rCjKVky8Y4MzjbRQq1Jdfg== X-Google-Smtp-Source: AA6agR6cLJFEsl3AJArEYDgQd93yC5d98d7pBkVtPyhBL2/V4VYcf5vCmeKibDsuIv+RoGsTzqvskz7X8QU4DA/Xz/E= X-Received: by 2002:a17:907:9620:b0:77d:4f86:2e66 with SMTP id gb32-20020a170907962000b0077d4f862e66mr3595860ejc.751.1662987824320; Mon, 12 Sep 2022 06:03:44 -0700 (PDT) MIME-Version: 1.0 References: <20210125153057.3623715-1-balsini@android.com> <20210125153057.3623715-4-balsini@android.com> In-Reply-To: From: Miklos Szeredi Date: Mon, 12 Sep 2022 15:03:33 +0200 Message-ID: Subject: Re: [PATCH RESEND V12 3/8] fuse: Definitions and ioctl for passthrough To: Amir Goldstein Cc: Alessio Balsini , Peng Tao , Akilesh Kailash , Antonio SJ Musumeci , David Anderson , Giuseppe Scrivano , Jann Horn , Jens Axboe , Martijn Coenen , Palmer Dabbelt , Paul Lawrence , Stefano Duo , Zimuzo Ezeozue , wuyan , fuse-devel , kernel-team , "linux-fsdevel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Mon, 12 Sept 2022 at 14:29, Amir Goldstein wrote: > > On Mon, Sep 12, 2022 at 12:29 PM Miklos Szeredi wrote: > > > > On Sat, 10 Sept 2022 at 10:52, Amir Goldstein wrote: > > > BTW, I see that the Android team is presenting eBPF-FUSE on LPC > > > coming Tuesday [1]. > > > > At first glance it looks like a filtered kernel-only passthrough + > > fuse fallback, where filtering is provided by eBPF scripts and only > > falls back to userspace access on more complex cases. Maybe it's a > > good direction, we'll see. > > Yeh, we'll see. > > > Apparently the passthrough case is > > important enough for various use cases. > > > > Indeed. > My use case is HSM and I think that using FUSE for HSM is becoming > more and more common these days. HSM? > > One of the things that bothers me is that both this FUSE_PASSTHROUGH > patch set and any future eBPF-FUSE passthrough implementation is > bound to duplicate a lot of code and know how from overlayfs > (along with the bugs). > > We could try to factor out some common bits to a kernel fs passthough > library. Yeah, although fuse/passthrough might not want all the complexity. Getting rid of the context switch latency is the easy part. Getting rid of dcache duplication is the hard one, though it seems that the current level of hacks in overlayfs seems sufficient and nobody much cares for the corner cases (or works around them). > > Anotehr options to consider is not to add any passthrough logic > to FUSE at all. > > Instead, implement a "switch" fs to choose between passthrough > to one of several underlying fs "branches", where one of the branches > could be local fs and another a FUSE fs (i.e. for the complex cases). st_dev/st_ino management might become a headache (as it is in overlayfs). Thanks, Miklos