[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACsf_wzQ526aEruo_R5h_JQZ4imkpZ+Ddg2NVFOGruJChPW0Ow@mail.gmail.com>
Date: Fri, 11 Mar 2016 22:32:07 +0200
From: Cole <cole@...eqint.net>
To: Richard Weinberger <richard@....at>
Cc: LKML <linux-kernel@...r.kernel.org>
Subject: Re: Variant symlink filesystem
On 11 March 2016 at 22:24, Richard Weinberger <richard@....at> 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?
Regards
/Cole
Powered by blists - more mailing lists