|
Hi David,
As I said earlier the inode is not linked with itable, so similar
to inode_path, inode_parent also won't work. We need to remember
the parent inode during the worm_create. May be we can store it in
the frame->local by creating a struct(if we have more than 2
elements to remember), or simply store it in the frame->local =
inode_ref(loc->parent). Please make sure to unref/free the
local.
Regards
Rafi KC
On 2/5/20 7:18 PM, David Spisla wrote:
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
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
Am Di., 4. Feb. 2020
um 17:57 Uhr schrieb Amar Tumballi < amar@xxxxxxxxx>:
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
--
Container Storage made easy!
|
