Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752051AbcCKUgi (ORCPT ); Fri, 11 Mar 2016 15:36:38 -0500 Received: from a.ns.miles-group.at ([95.130.255.143]:11949 "EHLO radon.swed.at" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750987AbcCKUgg (ORCPT ); Fri, 11 Mar 2016 15:36:36 -0500 Subject: Re: Variant symlink filesystem To: Cole References: <56E327FF.1010103@nod.at> <56E3298A.1040008@nod.at> Cc: LKML From: Richard Weinberger Message-ID: <56E32C51.80007@nod.at> Date: Fri, 11 Mar 2016 21:36:33 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1787 Lines: 43 Hi! Am 11.03.2016 um 21:32 schrieb Cole: > On 11 March 2016 at 22:24, Richard Weinberger wrote: >> Am 11.03.2016 um 21:22 schrieb Cole: >>> If I remember correctly, when we were testing the fuse version, we hard coded >>> the path to see if that solved the problem, and the difference between >>> the env lookup >>> code and the hard coded path was almost the same, but substantially slower than >>> the native file system. >> >> And where exactly as the performance problem? >> >> Anyway, if you submit your filesystem also provide a decent use case for it. :-) > > Thank you, I will do so. One example as a use case could be to allow > for multiple > package repositories to exist on a single computer, all in different > locations, but with > a fixed path so as not to break the package manager, the correct > repository then is > selected based on ENV variable. That way each user could have their own packages > installed that would be separate from the system packages, and no > collisions would > occur. > > If you don't mind me asking, are fuse based file systems meant to be as fast or > almost as fast as native or in-kernel filesystems? My last experience > with them was > that they were substantially slower. I also believe with our version > of the fuse filesytem > that we wrote, the env variable was only being looked up during mount, and then > remained static from there onwards. Do you believe that we should have > been able to > achieve performance almost as good as the in-kernel filesystems? FUSE filesystems are slower. But IMHO your use case cries for FUSE and it does not seem to be very performance critical as all you do is managing a symlink farm and redirecting. IOW all file io can go through the native filesystem. Thanks, //richard