Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752392AbcCKUcK (ORCPT ); Fri, 11 Mar 2016 15:32:10 -0500 Received: from mail-vk0-f52.google.com ([209.85.213.52]:36832 "EHLO mail-vk0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751510AbcCKUcI (ORCPT ); Fri, 11 Mar 2016 15:32:08 -0500 MIME-Version: 1.0 X-Originating-IP: [196.210.30.63] In-Reply-To: <56E3298A.1040008@nod.at> References: <56E327FF.1010103@nod.at> <56E3298A.1040008@nod.at> Date: Fri, 11 Mar 2016 22:32:07 +0200 Message-ID: Subject: Re: Variant symlink filesystem From: Cole To: Richard Weinberger Cc: LKML Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1454 Lines: 35 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? Regards /Cole