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 00B4F1382C5 for ; Mon, 22 Jun 2020 18:02:41 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0C611E087A; Mon, 22 Jun 2020 18:02:40 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (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 D6CBEE087A for ; Mon, 22 Jun 2020 18:02:39 +0000 (UTC) Message-ID: Subject: Re: [gentoo-soc] Weekly Report: Fusebox - FUSE Porwered sandbox project From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-soc@lists.gentoo.org Date: Mon, 22 Jun 2020 20:02:33 +0200 In-Reply-To: References: <2985923d2fecef8fa048048f77ef95fd27ea1516.camel@gentoo.org> Organization: Gentoo Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-f9DgJJxNjsBi2zgBaLvx" User-Agent: Evolution 3.36.3 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 X-Archives-Salt: 24a2a4ed-3f54-4cf6-b926-7db808e93f4c X-Archives-Hash: a5b593a09fa0cb5b67e6eb4b99c21753 --=-f9DgJJxNjsBi2zgBaLvx Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2020-06-23 at 01:17 +0900, Kaoru Esashika wrote: > Thank you for the reaction, Luca, Micha=C5=82. >=20 > I will expand my blog post soon. Thank you, Luca. >=20 > I want to answer the question from Micha=C5=82. >=20 > > 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? >=20 > 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. >=20 > > 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? >=20 > 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. This sounds a bit like premature optimization problem. Let's focus on getting a working solution first. You can look into improving performance with different inode solution later on. >=20 > > 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? >=20 > 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. >=20 > Thank you for your reply and support. >=20 > 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. >=20 Sure, please include anything that can help your readers understand what's going on with the project and why. --=20 Best regards, Micha=C5=82 G=C3=B3rny --=-f9DgJJxNjsBi2zgBaLvx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQGTBAABCgB9FiEEx2qEUJQJjSjMiybFY5ra4jKeJA4FAl7w8jpfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEM3 NkE4NDUwOTQwOThEMjhDQzhCMjZDNTYzOUFEQUUyMzI5RTI0MEUACgkQY5ra4jKe JA5xZggApoxAMpgKSz/f9krJlmb6Lhm5OW17+iXJjcaPjyjgQYPMo3LIzx2+LqqE xCtJKsoIQxfKozTgdick5YgTym3rImUd2RnWWbR5rNmlTXfS05tLrwZjFW53ztc5 rFpBw5S+3vuJ+eAeUzpriuXlVR1xYQDXGX0zMVt0VG4ZpXlOEMiN8GEKHdIqhBg4 2okbasYQPG7ofRYVX1XZOxVFAsfviqlemwx0uDVKL43j8+INMMorxPlPeE7S4gm2 s4GCY9LuJkxSzGNZzC/2QLjKCNIUJ8BAcQe/NXMcgks9AEbCGWQYikDqCgMtqPCq 9Y3mgsqZF+OT59/WxOwqPMhYl6Y7TQ== =4jQj -----END PGP SIGNATURE----- --=-f9DgJJxNjsBi2zgBaLvx--