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 71651C6FA83 for ; Sun, 11 Sep 2022 10:15:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229962AbiIKKPF (ORCPT ); Sun, 11 Sep 2022 06:15:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47010 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229968AbiIKKPD (ORCPT ); Sun, 11 Sep 2022 06:15:03 -0400 Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 588CB15704 for ; Sun, 11 Sep 2022 03:15:02 -0700 (PDT) Received: by mail-vs1-xe34.google.com with SMTP id h1so6130980vsr.11 for ; Sun, 11 Sep 2022 03:15:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=3creKp+0gQrX4E2fKo5+13Jvd4SrVIi5E+YlSTNV0jU=; b=l4R0wZrl9FUHQwPexgPvvpNVmgyazZtNF0nIkk9YGgqLiJ3wkeuZJbR2xZa4AuRyzS BV+9pyndLae/QDXHbd7b193eVMkzDPqkwvJ7zHijE3H4V5dZdsne/+vuioqXuuWDGLqC 0tZmmu9Z73XCbi65OfY7f/VnjTKB3bL4d4o5IldKvh6m3v0b7Ye08hOvy/+KizkAjDbv nSExmyX7m/Mz11QY8Rd6RLRg6mE0UmxKKqDTHhDbmN3komIQJ0fjjM8/W5w/HX36tj8P is0vBg9yCPl4sL6NXIZj8V5Cw7KF38QadzdEPyeN+cHHLFRCzDuS7u7CDX/7fv54RCH1 0PRQ== 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=3creKp+0gQrX4E2fKo5+13Jvd4SrVIi5E+YlSTNV0jU=; b=plWBhKN95wjajEOTStXDcN6Nm+TAJoLiMFk1ZPfzD/IKYBa6zokuyMOGkaMXAtFW98 AGARVsMHAhK7rQpLpBSB5nU0KXC/hG6hD3DK0QBXH2XPK3lNPSXBA2i33IeOYKuKs+Qe Ee3jF/+PzpPN/0KcUT8E7L77zh4QUc0GlUjxzM/WnVrXglbWq5wpa00W3SXgNjo6HSF9 010X6Vlay5qcNduLDtayI57l5cCpvaiVnMtNDYf/na/ynSBzYUOX47li2s3IzyUmZSO6 ua4CeH+gXBiPZhd9/u5yhbs2VhLG+cMnzYpLItO+RREaA4ECys85tDNXxFTCK0hTACa6 6BKA== X-Gm-Message-State: ACgBeo18VmpEaz8ZQnQhZVn+KMk+cXt8elXnMoLStU2KPRaxmkWQbWqK AZFfvecMKjTqBT6XPKEUixyqHX6NqDwizLwYOe6uOARS95A= X-Google-Smtp-Source: AA6agR5ZWhjMp8Yep/X3zkeZIznoVizAQsPsCfR1QFSK/eX/EUtosXpo25cf9f8fuH23hoTTZvmPFl4uWnHTWi+Hcb0= X-Received: by 2002:a05:6102:d3:b0:398:6f6a:8850 with SMTP id u19-20020a05610200d300b003986f6a8850mr1238060vsp.71.1662891301452; Sun, 11 Sep 2022 03:15:01 -0700 (PDT) MIME-Version: 1.0 References: <1bb71cbf-0a10-34c7-409d-914058e102f6@virtuozzo.com> <20200922210445.GG57620@redhat.com> In-Reply-To: From: Amir Goldstein Date: Sun, 11 Sep 2022 13:14:49 +0300 Message-ID: Subject: Re: Persistent FUSE file handles (Was: virtiofs uuid and file handles) To: Miklos Szeredi Cc: Vivek Goyal , linux-fsdevel , Hanna Reitz Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Wed, Sep 23, 2020 at 10:44 AM Miklos Szeredi wrote: > > One proposal was to add LOOKUP_HANDLE operation that is similar to > LOOKUP except it takes a {variable length handle, name} as input and > returns a variable length handle *and* a u64 node_id that can be used > normally for all other operations. > > The advantage of such a scheme for virtio-fs (and possibly other fuse > based fs) would be that userspace need not keep a refcounted object > around until the kernel sends a FORGET, but can prune its node ID > based cache at any time. If that happens and a request from the > client (kernel) comes in with a stale node ID, the server will return > -ESTALE and the client can ask for a new node ID with a special > lookup_handle(fh, NULL). > > Disadvantages being: > > - cost of generating a file handle on all lookups > - cost of storing file handle in kernel icache > > I don't think either of those are problematic in the virtiofs case. > The cost of having to keep fds open while the client has them in its > cache is much higher. > I was thinking of taking a stab at LOOKUP_HANDLE for a generic implementation of persistent file handles for FUSE. The purpose is "proper" NFS export support for FUSE. "proper" being survives server restart. I realize there is an ongoing effort to use file handles in the virtiofsd instead of open fds and that LOOKUP_HANDLE could assist in that effort, but that is an added benefit. I have a C++ implementation [1] which sort of supports persistent file handles, but not in a generic manner. If anyone knows of any WIP on LOOKUP_HANDLE please let me know. Thanks, Amir. [1] https://github.com/amir73il/libfuse/commits/fuse_passthrough