[Gluster-devel] Simulating some kind of "virtual file"

[Xavi Hernandez]

Hi David,

On Tue, Jan 9, 2018 at 9:09 AM, David Spisla <spisla80 at googlemail.com>
wrote:

> Dear Gluster Devels,
>
> at the moment I do some Xlator stuff and I want to know if there is a way
> to simulate the existing of a file to the client. It should be a kind of
> "virtual file". Here are more details.
>
> 1. Client lookup for a file e.g. "apple.test". This file does not exist in
> the backend
> $ ls -l apple.test
> ls: cannot access apple.test: No such file or directory
>
> Normally the system will not find that file
>
> 2. In the backend I have a real file called  e.g. "apple". Now there is a
> Xlator which manipulates the lookup request and is looking for the file
> "apple" instead of "apple.test". Gluster finds the file "apple" and the
> client will get a message from gluster that there is a file called
> "apple.test" with the attributes of the file "apple" (maybe we can
> manipulate that attributes too).
>

Intercepting lookup is fine to be able to manipulate "virtual files",
however it's not enough to completely operate on virtual files. You
basically need to intercept all file operations that work on a loc or are
path based and do the translation. You also need to intercept answers from
readdir and readdirp to do the reverse transformation so that the user sees
the virtual name and not the real name stored on the bricks.


>
> $ ls -l apple.test
> -rw-r--r-- 1 davids davids 0 Jan  5 15:42 apple.test
>
> My first idea is, to have a special lookup and lookup_cbk in some Xlator
> in the server stack. Or it is better to have this Xlator in the Client
> Stack?
>

That depends on what you are really trying to do. If you don't need any
information or coordination with other bricks, you can safely create the
xlator in the server stack.

The lookup function has a parameter called "loc_t *loc". In a first test I
> tried to manipulate loc->name and loc-path. If I manipulate loc->path I got
> an error and my volume crashed.
>

You should be able to modify the loc without causing any crash. However
there are some details you must be aware of:

   - loc->path and/or loc->name can be NULL in some cases.
   - If loc->path and loc->name are not NULL, loc->name always points to a
   substring of loc->path. It's not allocated independently (and so it must
   not be freed).
   - If you change loc->path, you also need to change loc->name (to point
   to the basename of loc->path)
   - You shouldn't change the contents of loc->path directly. It's better
   to allocate a new string with the modified path and assign it to loc->path
   (you need to free the old value of loc->path to avoid memory leaks).

I think this should be enough to correctly change loc->path and loc->name.

Xavi


> Any hints?
>
> Regards
> David Spisla
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20180109/0ab9562e/attachment.html>