Hide Forgot
The solution involves supporting relative paths in libglusterfsclient.
From Gluster-users list by Sudipto Mukhopadhyay: This could be tricky as you don't want too lookup too many alternatives!! But, as you are doing LD_PRELOAD, can you not ask the application to specify the paths (I know it's going to be little error prone based on what application supplies) For example: /mnt/glusterfs If the application run dir is /mnt/application then, ../glusterfs is another way to get to the glusterfs. So, for both the paths the booster intercepts the calls... Thanks and regards, Sudipto -----Original Message----- From: Shehjar Tikoo [shehjart] Sent: Monday, July 20, 2009 11:28 PM To: Sudipto Mukhopadhyay Cc: service; avati; gluster-users Subject: Re: [Gluster-users] Regarding 2.0.4 booster Sudipto Mukhopadhyay wrote: > > Makes sense. > > Yes I am running the same program. > > I will be running couple of more tests to verify this. > > BTW. two more questions on the related topics: > > > > 1. How much of performance boost does booster provide? That it provides a performance boost is evident from some of our tests and from reports from users. The exact improvement really depends on various factors such as the volume configuration, the type of translators used, the network setup, etc. > > 2. does the following > > http://www.gluster.org/docs/index.php/BoosterConfiguration#Virtual_Mount > > _Points > > mean that from the application we always need to use absolute path to > > the files being operated? > > That is a good question. I've also considered the need to remove the dependency on absolute paths but the use cases have been limited or none, till now to help me evolve the exact behaviour. Could you please describe what exactly you have in mind? I could take it from there. One approach is to redirect file system operations into GlusterFS when booster sees a string identifier or a token prepended to a path. This token could be specified through the booster.conf file. Since there will be no / prepended to this string, it does not remain an absolute path anymore. Also, since this is a global string identifier for booster, it is very different from a relative path, so can be used from anywhere in the local file system tree, as long as booster knows where to redirect these operations. Thanks Shehjar
Patch submitted for supporting relative paths is now under review, on the way to be available in the repo soon.
I've encountered some cases in my tests with the relative path support patch. These are cases which have basically blocked further progress on supporting relative paths. I'll provide more details after a few more tests.
Due to recent hard requirements of getting samba to work and the problem that samba uses relative paths to operate over the VMP, I am now submitting patches that support relative paths for samba only. Du has extended my previous patch for this bug to support generalized relative paths. I feel that is a bit extensive change and needs more careful testing and QA and will take longer than the time we have for supporting samba. We'll eventually move to using that patch.
PATCH: http://patches.gluster.com/patch/2080 in master (booster, libglusterfsclient: Support samba specific relative paths)
PATCH: http://patches.gluster.com/patch/2084 in release-2.0 (booster, libglusterfsclient: Support samba specific relative paths)
A more comprehensive solution to the relative path support is now undergoing testing. Du is maintaining the progress on that in bz 369. *** This bug has been marked as a duplicate of bug 369 ***