[Gluster-devel] WORM-Xlator: How to get filepath in worm_create_cbk?

[David Spisla]

Hello Rafi,
I understand. I first tried the way with the parent inode. I did it this
way:

inode_t *parent_inode = NULL;
char *filepath = NULL;
parent_inode = inode_parent(inode, NULL, NULL); // also with fd->inode it
didn't work
if (!parent_inode) {
  gf_log(this->name, GF_LOG_ERROR, "Can't get parent inode!");
}
inode_path(parent_inode, NULL, &filepath);
if (!filepath) {
   gf_log(this->name, GF_LOG_ERROR, "Can't get filepath!");
}

But it didn't work. See brick log:
[2020-02-05 13:39:56.408915] E [worm.c:489:worm_create_cbk] 0-repo2-worm:
Can't get parent inode!
[2020-02-05 13:39:56.408941] E [worm.c:495:worm_create_cbk] 0-repo2-worm:
Can't get filepath!

What could be wrong? If this way promise no succeed I will try out the
other approach you suggested.

Regards
David Spisla

Am Mi., 5. Feb. 2020 um 12:00 Uhr schrieb RAFI KC <rkavunga at redhat.com>:

>
> On 2/5/20 4:15 PM, David Spisla wrote:
>
> Hello Amar,
> I do the following in worm_create_cbk:
>
> char *filepath = NULL;
> inode_path(inode, NULL, &filepath);
> if (!filepath) {
>     gf_log(this->name, GF_LOG_ERROR, "Can't get filepath!");
> }
>
> Unfortunately I got this in the brick log:
> [2020-02-05 10:09:41.880522] E [inode.c:1498:__inode_path]
> (-->/usr/lib64/glusterfs/5.11/xlator/features/worm.so(+0xb129)
> [0x7f4657df7129] -->/usr/lib64/libglusterfs.so.0(inode_path+0x31)
> [0x7f4664e44961] -->/us
> r/lib64/libglusterfs.so.0(__inode_path+0x38b) [0x7f4664e448bb] ) 0-:
> Assertion failed: 0
> [2020-02-05 10:09:41.880580] W [inode.c:1500:__inode_path]
> (-->/usr/lib64/glusterfs/5.11/xlator/features/worm.so(+0xb129)
> [0x7f4657df7129] -->/usr/lib64/libglusterfs.so.0(inode_path+0x31)
> [0x7f4664e44961] -->/us
> r/lib64/libglusterfs.so.0(__inode_path+0x3d3) [0x7f4664e44903] )
> 0-repo2-worm: invalid inode [Invalid argument]
> [2020-02-05 10:09:41.880594] E [worm.c:488:worm_create_cbk] 0-repo2-worm:
> Can't get filepath!
>
> The inode I use seems to be not valid because inode_path() returns with
> error. The same with fd->inode. Is there a way to validate the inode before
> passing it to the function?
>
> This inode hasn't linked yet to the inode table(creation is still in
> progress), that will only happens at server4_post_create from the server
> xlator which is the last xlator in the cbk path. That is why the inode_path
> creation is failed. Why don't you use parent inode to create the path, I
> believe parent inode will work for you.
>
>
> If all the files and folders in the special directory follows the same
> property, An alternative approach is to use an inode type to distinguish
> this special directory and dentries on it. Something similar to
> snapview-client which uses virtual inode to distinguish the .snap folder.
>
>
> Regards
>
> Rafi KC
>
>
>
>
> Regards
> David
>
>
>
> Am Di., 4. Feb. 2020 um 17:57 Uhr schrieb Amar Tumballi <amar at kadalu.io>:
>
>>
>>
>> On Tue, Feb 4, 2020 at 7:16 PM David Spisla <spisla80 at gmail.com> wrote:
>>
>>> Dear Gluster Community,
>>> in worm_create_cbk a file gets the xattr "trusted.worm_file" and
>>> "trusted.start_time" if worm-file-level is enabled. Now I want to exclude
>>> some files in a special folder from the WORM function. Therefore I want to
>>> check in worm_create_cbk if the file is in this folder or not. But I don't
>>> find a parameter where the filepath is stored. So my alternative solution
>>> was, to check it in worm_create (via loc->path) and store a boolean value
>>> in frame->local. This boolean value will be used in worm_create_cbk later.
>>> But its not my favourite solution.
>>>
>>>
>> Do you know how to get the filepath in the cbk function?
>>>
>>>
>> As per FS guidelines, inside the filesystem, we need to handle inodes or
>> parent-inode + basename. If you are looking at building a 'path' info in
>> create_cbk, then i recommend using 'inode_path()' to build the path as per
>> the latest inode table information.
>>
>> -Amar
>>
>>
>> --
>> https://kadalu.io
>> Container Storage made easy!
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20200205/55f22637/attachment.html>