lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ