From: Richard Weinberger <richard@nod.at>
To: Cole <cole@opteqint.net>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: Variant symlink filesystem
Date: Fri, 11 Mar 2016 21:36:33 +0100 [thread overview]
Message-ID: <56E32C51.80007@nod.at> (raw)
In-Reply-To: <CACsf_wzQ526aEruo_R5h_JQZ4imkpZ+Ddg2NVFOGruJChPW0Ow@mail.gmail.com>
Hi!
Am 11.03.2016 um 21:32 schrieb Cole:
> On 11 March 2016 at 22:24, Richard Weinberger <richard@nod.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?
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
next prev parent reply other threads:[~2016-03-11 20:36 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-11 16:20 Variant symlink filesystem Cole
2016-03-11 16:44 ` Austin S. Hemmelgarn
2016-03-11 20:04 ` Richard Weinberger
2016-03-11 20:15 ` Cole
2016-03-11 20:18 ` Richard Weinberger
2016-03-11 20:22 ` Cole
2016-03-11 20:24 ` Richard Weinberger
2016-03-11 20:32 ` Cole
2016-03-11 20:36 ` Richard Weinberger [this message]
2016-03-11 22:27 ` David Lang
2016-03-11 20:38 ` Austin S. Hemmelgarn
2016-03-11 20:52 ` Cole
2016-03-11 21:51 ` Al Viro
2016-03-11 22:03 ` Cole
2016-03-11 22:24 ` Al Viro
2016-03-11 22:31 ` Cole
2016-03-11 22:48 ` David Lang
2016-03-11 22:54 ` Cole
2016-03-11 22:38 ` David Lang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56E32C51.80007@nod.at \
--to=richard@nod.at \
--cc=cole@opteqint.net \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.