From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 9DCA41382C5 for ; Mon, 22 Jun 2020 16:17:37 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id ADA9FE090F; Mon, 22 Jun 2020 16:17:36 +0000 (UTC) Received: from mail-io1-f67.google.com (mail-io1-f67.google.com [209.85.166.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id A3FF8E090F for ; Mon, 22 Jun 2020 16:17:36 +0000 (UTC) Received: by mail-io1-f67.google.com with SMTP id s18so20175704ioe.2 for ; Mon, 22 Jun 2020 09:17:36 -0700 (PDT) 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:content-transfer-encoding; bh=5uG7PwY7tGiHiE+g+P2adAqBqieWgGBB7yXTeoUr/3o=; b=mDZJItkRUGbrIoMCM9tGwr8tC1zVH5Bv4TEaSHHJmWuO5zpI4uNAhQqHsBUqEavt9L t3+DV6W0nZb1GziNy20iod1dM1V6ZrCEwqhWKi+XcPPD5Z2VTtC8ANszKkoKuXYaXyLc DWcOgsahQvDSCCCp5DDcrYOeZWtnEHPbzfbG6t8prdfZIWw4XszZnWnnH25HKkeegwEx YBy01PUUOwFXOw9kZQJKH1RlVWvY4tPdel83DIyNR3U6p1nxRq5UfyvYLQSQVHrKkJiC KxW283lM3cFDcSmzTybNqhIIeQbAthNN6WxIl3HGkWwTFNMMb142gwcO45kIlTcXYhwx nV/w== X-Gm-Message-State: AOAM531n6qausTk84R66o68BiOVpE2L1SWcpG0WqnaGX83muwCWgmU+c W/CIj1UO9+gZLN6waSB1CmE5v7NhyQgIfL+1SaRCZ85m X-Google-Smtp-Source: ABdhPJxwn9PdMIU+yUn2t3szNU/Pdwr/XGMsiGnOm6xL8708vcuw1pGgBLB2OM+VGTvz4vzWiFwdxdLc3vMtauRGugg= X-Received: by 2002:a6b:e617:: with SMTP id g23mr20526584ioh.103.1592842655689; Mon, 22 Jun 2020 09:17:35 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-soc@lists.gentoo.org Reply-to: gentoo-soc@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 References: <2985923d2fecef8fa048048f77ef95fd27ea1516.camel@gentoo.org> In-Reply-To: <2985923d2fecef8fa048048f77ef95fd27ea1516.camel@gentoo.org> From: Kaoru Esashika Date: Tue, 23 Jun 2020 01:17:24 +0900 Message-ID: Subject: Re: [gentoo-soc] Weekly Report: Fusebox - FUSE Porwered sandbox project To: gentoo-soc@lists.gentoo.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 888a66be-ab4b-48fc-baab-0cfc90f012af X-Archives-Hash: 680af7d246cf33230327cc70f7ec1fe4 Thank you for the reaction, Luca, Micha=C5=82. I will expand my blog post soon. Thank you, Luca. I want to answer the question from Micha=C5=82. > 1. From our talking you indicated that FUSE has both high-level and low- > level API. However, the post only hints at it. Could you explain both > shortly and why you've chosen the one you've chosen? There are some FUSE libraries which I can choose. But actively maintenanced ones are pyfuse3 and libfuse (both are developed by the same person). pyfuse3 is an asynchronous python library. I call it 'low-level' because functions that should be implemented are called with inode arguments. libfuse is a C library. It has two interfaces, high-level synchronous one and low-level asynchronous one. The difference between the two is whether arguments are path or inode. So, with the exception of libraries that are no longer maintained, the only choice is pyfuse3. > 2. How are you planning to deal with the essential problem that > the underlying directory tree may consist of multiple filesystems with > different files having colliding inode numbers? VFS in the kernel and programs in userland expects consistency with regard to inode, so Fusebox should provide a unique inode for each file. Fusebox can do this by finding out which device the file belongs to. Then remember mappings from/to device-inode pairs to/from 'virtual' inode. However, I worried this solution hits performance since it potentially causes many stat() system calls. > 3. How do other passthrough filesystems deal with the same problem? > What are the advantages/disadvantages of different approaches you've > considered, and why did you chose this solution? I investigated the high-level interface of libfuse. It caches the reply of the user program. and automatically convert inode and path. So the high-level interface of libfuse will affect the problem. I also investigate sandboxfs ( https://github.com/bazelbuild/sandboxfs ). I think it take same strategy to Fusebox. sandboxfs construct filesystem tree virtually on memory and notice virtual inode to user application. This approach may hit performance because of frequent stat() call, but I cannot think better approaches. Thank you for your reply and support. Would you mind if I publish this mail on my blog, Micha=C5=82? It was a worthwhile discussion and I'd like to share it on my blog. Regards, Kaoru Esashika