Messages in this thread | | | Subject | Re: Variant symlink filesystem | From | Richard Weinberger <> | Date | Fri, 11 Mar 2016 21:36:33 +0100 |
| |
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
| |