Re: [Gluster-devel] [Gluster-users] Using Ganesha v2.8.4 with Gluster v5.11 ???
Thanks for the clarification. David Spisla Software Engineer david.spi...@iternity.com +49 761 59034852 iTernity GmbH Heinrich-von-Stephan-Str. 21 79100 Freiburg Germany Website Newsletter Support Portal See our privacy policy if you want us to delete your personal data. iTernity GmbH. Managing Director: Ralf Steinemann. Registered at the District Court Freiburg: HRB-Nr. 701332. USt.Id DE242664311. [v01.023] Von: Kaleb Keithley Gesendet: Montag, 22. März 2021 15:52 An: David Spisla Cc: gluster-us...@gluster.org List ; Gluster Devel Betreff: Re: [Gluster-users] Using Ganesha v2.8.4 with Gluster v5.11 ??? I was wrong: nfs-ganesha-2.8's fsal_gluster calls glfs_ftruncate() and glfs_fsync(), which appeared in glusterfs-6.0. Sorry for any confusion. -- Kaleb On Mon, Mar 22, 2021 at 10:07 AM Kaleb Keithley mailto:kkeit...@redhat.com>> wrote: GFAPI_6.0 is a reference to a set of versioned symbols in gluster's libgfapi. As the version implies, you need at least glusterfs-6.0 to run nfs-ganesha-2.8.x. Although it's not clear — without further investigation — why the rpm has derived that dependency. I'm not seeing that the gluster FSAL in ganesha-2.8.x calls any of the GFAPI_6.0 apis. Or any of the later GFAPI_6.x apis. It seems to me like nfs-ganesha-2.8.x could be compiled with glusterfs-5 and would work fine. -- Kaleb On Mon, Mar 22, 2021 at 8:15 AM David Spisla mailto:spisl...@gmail.com>> wrote: Dear Gluster Community and Devels, at the moment we are using Ganesha 2.7.6 with Glusterv5.11 Now we want to update ganesha from 2.7.6 to 2.8.4 . I just tried to update ganesha on a 2-node SLES15SP1 cluster with the above mentioned versions. I got the packages from here: https://download.opensuse.org/repositories/home:/nfs-ganesha:/SLES15SP1-nfs-ganesha-2.8/SLE_15_SP1/x86_64/ But I got the following dependency error: fs-davids-c3-n1:~ # zypper install libntirpc1_8-1.8.1-2.2.x86_64.rpm nfs-ganesha-2.8.4-5.2.x86_64.rpm nfs-ganesha-gluster-2.8.4-5.2.x86_64.rpm nfs-ganesha-vfs-2.8.4-5.2.x86_64.rpm Loading repository data... Reading installed packages... Resolving package dependencies... Problem: nothing provides libgfapi.so.0(GFAPI_6.0)(64bit) needed by nfs-ganesha-gluster-2.8.4-5.2.x86_64 Solution 1: do not install nfs-ganesha-gluster-2.8.4-5.2.x86_64 Solution 2: break nfs-ganesha-gluster-2.8.4-5.2.x86_64 by ignoring some of its dependencies Choose from above solutions by number or cancel [1/2/c/d/?] (c): c Does anybody of you know to which Gluster version GFAPI_6.0 refers? Is it posible at all to run ganesha 2.8.4 with gluster 5.11? Regards David Spisla Community Meeting Calendar: Schedule - Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC Bridge: https://meet.google.com/cpu-eiue-hvk Gluster-users mailing list gluster-us...@gluster.org<mailto:gluster-us...@gluster.org> https://lists.gluster.org/mailman/listinfo/gluster-users --- Community Meeting Calendar: Schedule - Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC Bridge: https://meet.google.com/cpu-eiue-hvk Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] [Gluster-users] Using Ganesha v2.8.4 with Gluster v5.11 ???
Thanks for the answer. Its a pitty that ganesha 2.8.4 doesn’t runs out of the box with gluster 5.11 David Spisla Software Engineer david.spi...@iternity.com +49 761 59034852 iTernity GmbH Heinrich-von-Stephan-Str. 21 79100 Freiburg Germany Website Newsletter Support Portal See our privacy policy if you want us to delete your personal data. iTernity GmbH. Managing Director: Ralf Steinemann. Registered at the District Court Freiburg: HRB-Nr. 701332. USt.Id DE242664311. [v01.023] Von: Kaleb Keithley Gesendet: Montag, 22. März 2021 15:08 An: David Spisla Cc: gluster-us...@gluster.org List ; Gluster Devel Betreff: Re: [Gluster-users] Using Ganesha v2.8.4 with Gluster v5.11 ??? GFAPI_6.0 is a reference to a set of versioned symbols in gluster's libgfapi. As the version implies, you need at least glusterfs-6.0 to run nfs-ganesha-2.8.x. Although it's not clear — without further investigation — why the rpm has derived that dependency. I'm not seeing that the gluster FSAL in ganesha-2.8.x calls any of the GFAPI_6.0 apis. Or any of the later GFAPI_6.x apis. It seems to me like nfs-ganesha-2.8.x could be compiled with glusterfs-5 and would work fine. -- Kaleb On Mon, Mar 22, 2021 at 8:15 AM David Spisla mailto:spisl...@gmail.com>> wrote: Dear Gluster Community and Devels, at the moment we are using Ganesha 2.7.6 with Glusterv5.11 Now we want to update ganesha from 2.7.6 to 2.8.4 . I just tried to update ganesha on a 2-node SLES15SP1 cluster with the above mentioned versions. I got the packages from here: https://download.opensuse.org/repositories/home:/nfs-ganesha:/SLES15SP1-nfs-ganesha-2.8/SLE_15_SP1/x86_64/ But I got the following dependency error: fs-davids-c3-n1:~ # zypper install libntirpc1_8-1.8.1-2.2.x86_64.rpm nfs-ganesha-2.8.4-5.2.x86_64.rpm nfs-ganesha-gluster-2.8.4-5.2.x86_64.rpm nfs-ganesha-vfs-2.8.4-5.2.x86_64.rpm Loading repository data... Reading installed packages... Resolving package dependencies... Problem: nothing provides libgfapi.so.0(GFAPI_6.0)(64bit) needed by nfs-ganesha-gluster-2.8.4-5.2.x86_64 Solution 1: do not install nfs-ganesha-gluster-2.8.4-5.2.x86_64 Solution 2: break nfs-ganesha-gluster-2.8.4-5.2.x86_64 by ignoring some of its dependencies Choose from above solutions by number or cancel [1/2/c/d/?] (c): c Does anybody of you know to which Gluster version GFAPI_6.0 refers? Is it posible at all to run ganesha 2.8.4 with gluster 5.11? Regards David Spisla Community Meeting Calendar: Schedule - Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC Bridge: https://meet.google.com/cpu-eiue-hvk Gluster-users mailing list gluster-us...@gluster.org<mailto:gluster-us...@gluster.org> https://lists.gluster.org/mailman/listinfo/gluster-users --- Community Meeting Calendar: Schedule - Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC Bridge: https://meet.google.com/cpu-eiue-hvk Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] Using Ganesha v2.8.4 with Gluster v5.11 ???
Dear Gluster Community and Devels, at the moment we are using Ganesha 2.7.6 with Glusterv5.11 Now we want to update ganesha from 2.7.6 to 2.8.4 . I just tried to update ganesha on a 2-node SLES15SP1 cluster with the above mentioned versions. I got the packages from here: https://download.opensuse.org/repositories/home:/nfs-ganesha:/SLES15SP1-nfs-ganesha-2.8/SLE_15_SP1/x86_64/ But I got the following dependency error: > fs-davids-c3-n1:~ # zypper install libntirpc1_8-1.8.1-2.2.x86_64.rpm > nfs-ganesha-2.8.4-5.2.x86_64.rpm nfs-ganesha-gluster-2.8.4-5.2.x86_64.rpm > nfs-ganesha-vfs-2.8.4-5.2.x86_64.rpm > Loading repository data... > Reading installed packages... > Resolving package dependencies... > > Problem: nothing provides libgfapi.so.0(GFAPI_6.0)(64bit) needed by > nfs-ganesha-gluster-2.8.4-5.2.x86_64 > Solution 1: do not install nfs-ganesha-gluster-2.8.4-5.2.x86_64 > Solution 2: break nfs-ganesha-gluster-2.8.4-5.2.x86_64 by ignoring some > of its dependencies > > Choose from above solutions by number or cancel [1/2/c/d/?] (c): c > Does anybody of you know to which Gluster version GFAPI_6.0 refers? Is it posible at all to run ganesha 2.8.4 with gluster 5.11? Regards David Spisla --- Community Meeting Calendar: Schedule - Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC Bridge: https://meet.google.com/cpu-eiue-hvk Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] WORM-Xlator: How to get filepath in worm_create_cbk?
Hello Rafi,
storing the parent inode in frame->local from worm_create() succeed, but
now there is another error. Its frustrating, so I gave it up and proceed
with my initial solution:
In worm_create() I check via helper function (using loc->path) , if the
file should be ready for WORM or not. If not I set frame->local with
gf_true and catch the value in worm_create_cbk to skip setting the xattr.
It is working stable!
Regards
David
Am Mi., 5. Feb. 2020 um 20:51 Uhr schrieb RAFI KC :
> 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, );
> 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 :
>
>>
>> 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, );
>> 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 :
>>
>>>
>>>
>>> On Tue, Feb 4, 2020 at 7:16 PM David Spisla 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 do
Re: [Gluster-devel] WORM-Xlator: How to get filepath in worm_create_cbk?
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, );
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 :
>
> 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, );
> 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 :
>
>>
>>
>> On Tue, Feb 4, 2020 at 7:16 PM David Spisla 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!
>>
>>
___
Community Meeting Calendar:
APAC Schedule -
Every 2nd and 4th Tuesday at 11:30 AM IST
Bridge: https://bluejeans.com/441850968
NA/EMEA Schedule -
Every 1st and 3rd Tuesday at 01:00 PM EDT
Bridge: https://bluejeans.com/441850968
Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] WORM-Xlator: How to get filepath in worm_create_cbk?
Hello Amar,
I do the following in worm_create_cbk:
char *filepath = NULL;
inode_path(inode, NULL, );
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?
Regards
David
Am Di., 4. Feb. 2020 um 17:57 Uhr schrieb Amar Tumballi :
>
>
> On Tue, Feb 4, 2020 at 7:16 PM David Spisla 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!
>
>
___
Community Meeting Calendar:
APAC Schedule -
Every 2nd and 4th Tuesday at 11:30 AM IST
Bridge: https://bluejeans.com/441850968
NA/EMEA Schedule -
Every 1st and 3rd Tuesday at 01:00 PM EDT
Bridge: https://bluejeans.com/441850968
Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] WORM-Xlator: How to get filepath in worm_create_cbk?
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? Regards David Spisla ___ Community Meeting Calendar: APAC Schedule - Every 2nd and 4th Tuesday at 11:30 AM IST Bridge: https://bluejeans.com/441850968 NA/EMEA Schedule - Every 1st and 3rd Tuesday at 01:00 PM EDT Bridge: https://bluejeans.com/441850968 Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Introduce GD_OP_VERSION_5_10 and increase GD_OP_VERSION_MAX to this version
Hello Atin, thank you. It working fine! Regards David Am Mi., 29. Jan. 2020 um 10:15 Uhr schrieb Atin Mukherjee < atin.mukherje...@gmail.com>: > There’s no hard requirement to have an op-version tagged against a release > until and unless you introduce a new volume option. What you need to do is > introduce a new macro with a higher value than max op version and set the > max op version value to the same - just like how a new volume option is > introduced. If you introduce a new macro with a value lower than max op > version you’re calling for a trouble with backward compatibility and > managing heterogeneous cluster. > > HTH > > On Wed, 29 Jan 2020 at 14:28, David Spisla wrote: > >> Dear Gluster Devels, >> i am using gluster 5.10 and want to introduce a new volume option. >> Therefore I want to set a proper GD_OP_VERSION for it. In gluster 5.10 >> source code there is no macro defined for 51000. >> >> But concurrently the GD_OP_VERSION_MAX is set to 50400. I would do >> something like this: >> >> 1. Change in libglusterfs/src/globals-h (line 47) >> #define GD_OP_VERSION_MAX >> \ >> GD_OP_VERSION_5_10 >> 2. Add line to same Header file: >> #define GD_OP_VERSION_5_10 51000 /* Op-version for GlusterFS 5.10 */ >> >> Do you think this is fine? >> >> 3. libglusterfs/src/common-utils.c (line 2036): >> On the other side there is a if-branch which uses GD_OP_VERSION_5_4 which >> is currently the GD_OP_VERSION_MAX. Why it is used here and should I >> increase it also to GD_OP_VERSION_5_10? >> >> Regards >> David Spisla >> ___ >> >> Community Meeting Calendar: >> >> APAC Schedule - >> Every 2nd and 4th Tuesday at 11:30 AM IST >> Bridge: https://bluejeans.com/441850968 >> >> >> NA/EMEA Schedule - >> Every 1st and 3rd Tuesday at 01:00 PM EDT >> Bridge: https://bluejeans.com/441850968 >> >> Gluster-devel mailing list >> Gluster-devel@gluster.org >> https://lists.gluster.org/mailman/listinfo/gluster-devel >> >> -- > --Atin > ___ Community Meeting Calendar: APAC Schedule - Every 2nd and 4th Tuesday at 11:30 AM IST Bridge: https://bluejeans.com/441850968 NA/EMEA Schedule - Every 1st and 3rd Tuesday at 01:00 PM EDT Bridge: https://bluejeans.com/441850968 Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] Introduce GD_OP_VERSION_5_10 and increase GD_OP_VERSION_MAX to this version
Dear Gluster Devels, i am using gluster 5.10 and want to introduce a new volume option. Therefore I want to set a proper GD_OP_VERSION for it. In gluster 5.10 source code there is no macro defined for 51000. But concurrently the GD_OP_VERSION_MAX is set to 50400. I would do something like this: 1. Change in libglusterfs/src/globals-h (line 47) #define GD_OP_VERSION_MAX \ GD_OP_VERSION_5_10 2. Add line to same Header file: #define GD_OP_VERSION_5_10 51000 /* Op-version for GlusterFS 5.10 */ Do you think this is fine? 3. libglusterfs/src/common-utils.c (line 2036): On the other side there is a if-branch which uses GD_OP_VERSION_5_4 which is currently the GD_OP_VERSION_MAX. Why it is used here and should I increase it also to GD_OP_VERSION_5_10? Regards David Spisla ___ Community Meeting Calendar: APAC Schedule - Every 2nd and 4th Tuesday at 11:30 AM IST Bridge: https://bluejeans.com/441850968 NA/EMEA Schedule - Every 1st and 3rd Tuesday at 01:00 PM EDT Bridge: https://bluejeans.com/441850968 Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] Compiling Gluster RPMs for v5.x on Suse SLES15
Dear Gluster Community, I want to compile my own Gluster RPMs for v5.x on a Suse Sles15 machine. I am using the spec file from here: https://github.com/gluster/glusterfs-suse/blob/sles15-glusterfs-5/glusterfs.spec There is a Build Requirement 'rpcgen' which causes confusion to me. I had a chat with Kaleb Keithley a few months ago: https://lists.gluster.org/pipermail/gluster-users/2019-May/036518.html This statement seems to be interesting: „Miuku on #opensuse-buildservice poked around and found that the unbundled rpcgen in SLE_15 comes from the rpcsvc-proto rpm. (Not the rpcgen rpm as it does in Fedora and RHEL8.) All the gluster community packages for SLE_15 going back to glusterfs-5.0 in October 2018 have used the unbundled rpcgen. You can do the same, or remove the BuildRequires: rpcgen line and use the glibc bundled rpcgen.“ Unfortunately there is no rpcsvc-proto rpm for SLES15: https://software.opensuse.org/package/rpcsvc-proto?locale=fa I don't know where the guys from Suse OBS had this rpm from. There is maybe the way to compile the rpcsvc-proto src rpm on a SLES15, but this is no good solution in my opinion. So I tried to remove the 'rpcgen' requirement from the spec file and create the RPMs by using glibc bundled rpcgen according to Kalebs advise. It works and Gluster seems to be running stable. Do you think there are any risks in using glibc bundled rpcgen for creating Gluster 5.x RPMs or should I prefer the rpcgen from rpcsvc-proto rpm ? Regards David Spisla ___ Community Meeting Calendar: APAC Schedule - Every 2nd and 4th Tuesday at 11:30 AM IST Bridge: https://bluejeans.com/441850968 NA/EMEA Schedule - Every 1st and 3rd Tuesday at 01:00 PM EDT Bridge: https://bluejeans.com/441850968 Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] Bug: storage.reserve ignored by self-heal so that bricks are 100% full
Dear Gluster Community, just another bug found. See here for details: https://bugzilla.redhat.com/show_bug.cgi?id=1784402 Logs and Infos are provided in a file. Regards David Spisla ___ Community Meeting Calendar: APAC Schedule - Every 2nd and 4th Tuesday at 11:30 AM IST Bridge: https://bluejeans.com/441850968 NA/EMEA Schedule - Every 1st and 3rd Tuesday at 01:00 PM EDT Bridge: https://bluejeans.com/441850968 Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] Bugreport: Pending self-heal when bricks are full
Dear Gluster Community, see Bugreport for all details: https://bugzilla.redhat.com/show_bug.cgi?id=1784013 There is also a compressed file with logs and volume information. Regards David Spisla ___ Community Meeting Calendar: APAC Schedule - Every 2nd and 4th Tuesday at 11:30 AM IST Bridge: https://bluejeans.com/441850968 NA/EMEA Schedule - Every 1st and 3rd Tuesday at 01:00 PM EDT Bridge: https://bluejeans.com/441850968 Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Improve stability between SMB/CTDB and Gluster (together with Samba Core Developer)
Hi Poornima, thats fine. I would suggest this dates and times: May 15th – 17th at 12:30, 13:30, 14:30 IST (9:00, 10:00, 11:00 CEST) May 20th – 24th at 12:30, 13:30, 14:30 IST (9:00, 10:00, 11:00 CEST) I add Volker Lendecke from Sernet to the mail. He is the Samba Expert. Can someone of you provide a host via bluejeans.com? If not, I will try it with GoToMeeting (https://www.gotomeeting.com). @all Please write your prefered dates and times. For me, all oft the above dates and times are fine Regards David David Spisla Software Engineer david.spi...@iternity.com +49 761 59034852 iTernity GmbH Heinrich-von-Stephan-Str. 21 79100 Freiburg Deutschland Website Newsletter Support Portal iTernity GmbH. Geschäftsführer: Ralf Steinemann. Eingetragen beim Amtsgericht Freiburg: HRB-Nr. 701332. USt.Id DE242664311. [v01.023] Von: Poornima Gurusiddaiah Gesendet: Montag, 13. Mai 2019 07:22 An: David Spisla ; Anoop C S ; Gunther Deschner Cc: Gluster Devel ; gluster-us...@gluster.org List Betreff: Re: [Gluster-devel] Improve stability between SMB/CTDB and Gluster (together with Samba Core Developer) Hi, We would be definitely interested in this. Thank you for contacting us. For the starter we can have an online conference. Please suggest few possible date and times for the week(preferably between IST 7.00AM - 9.PM<http://9.PM>)? Adding Anoop and Gunther who are also the main contributors to the Gluster-Samba integration. Thanks, Poornima On Thu, May 9, 2019 at 7:43 PM David Spisla mailto:spisl...@gmail.com>> wrote: Dear Gluster Community, at the moment we are improving the stability of SMB/CTDB and Gluster. For this purpose we are working together with an advanced SAMBA Core Developer. He did some debugging but needs more information about Gluster Core Behaviour. Would any of the Gluster Developer wants to have a online conference with him and me? I would organize everything. In my opinion this is a good chance to improve stability of Glusterfs and this is at the moment one of the major issues in the Community. Regards David Spisla ___ Community Meeting Calendar: APAC Schedule - Every 2nd and 4th Tuesday at 11:30 AM IST Bridge: https://bluejeans.com/836554017 NA/EMEA Schedule - Every 1st and 3rd Tuesday at 01:00 PM EDT Bridge: https://bluejeans.com/486278655 Gluster-devel mailing list Gluster-devel@gluster.org<mailto:Gluster-devel@gluster.org> https://lists.gluster.org/mailman/listinfo/gluster-devel ___ Community Meeting Calendar: APAC Schedule - Every 2nd and 4th Tuesday at 11:30 AM IST Bridge: https://bluejeans.com/836554017 NA/EMEA Schedule - Every 1st and 3rd Tuesday at 01:00 PM EDT Bridge: https://bluejeans.com/486278655 Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Re-Compile glusterd1 and add it to the stack
You are rigth. When creating the patch file, I did a mistake. Attached should be the complete one Regards David Am Mo., 15. Juli 2019 um 17:20 Uhr schrieb Atin Mukherjee < amukh...@redhat.com>: > David - I don't see a GF_OPTION_INIT in init () of read-only.c . How is > that working even when you're compiling the entire source? > > On Mon, Jul 15, 2019 at 7:40 PM David Spisla wrote: > >> Hello Vijay, >> there is a patch file attached. You can see the code there. I oriented >> myself here: >> https://review.gluster.org/#/c/glusterfs/+/18633/ >> >> As you can see there is no additional code in glusterd-volgen.c . Both >> glusterd-volgen.c and glusterd-volume.set.c will be compiled into >> glusterd.so . >> Its still the problem, that my new option is not available if I only >> re-compile glusterd.so . Compiling and using the whole RPMs is working >> >> It is not possible to re-compile glusterd.so ? >> >> Regards >> David Spisla >> >> Am Do., 11. Juli 2019 um 20:35 Uhr schrieb Vijay Bellur < >> vbel...@redhat.com>: >> >>> Hi David, >>> >>> If the option is related to a particular translator, you would need to >>> add that option in the options table of the translator and add code in >>> glusterd-volgen.c to generate that option in the volfiles. >>> >>> Would it be possible to share the code diff that you are trying out? >>> >>> Regards, >>> Vijay >>> >>> On Wed, Jul 10, 2019 at 3:11 AM David Spisla wrote: >>> >>>> Hello Gluster Devels, >>>> >>>> I add a custom volume option to glusterd-volume-set.c . I could build >>>> my own RPMs but I don't want this, I only want to add new compiled glusterd >>>> to the stack. I tried it out to copy glusterd.so to >>>> /usr/lib64/glusterfs/x.x/xlator/mgmt . After this glusterd is running >>>> normally and I can create volumes but in the vol files my new option is not >>>> there and if I want to start the volume it failed. >>>> >>>> It seems to be that I need to add some other files to the stack. Any >>>> idea? >>>> >>>> Regards >>>> David Spisla >>>> ___ >>>> >>>> Community Meeting Calendar: >>>> >>>> APAC Schedule - >>>> Every 2nd and 4th Tuesday at 11:30 AM IST >>>> Bridge: https://bluejeans.com/836554017 >>>> >>>> NA/EMEA Schedule - >>>> Every 1st and 3rd Tuesday at 01:00 PM EDT >>>> Bridge: https://bluejeans.com/486278655 >>>> >>>> Gluster-devel mailing list >>>> Gluster-devel@gluster.org >>>> https://lists.gluster.org/mailman/listinfo/gluster-devel >>>> >>>> ___ >>> >>> Community Meeting Calendar: >>> >>> APAC Schedule - >>> Every 2nd and 4th Tuesday at 11:30 AM IST >>> Bridge: https://bluejeans.com/836554017 >>> >>> NA/EMEA Schedule - >>> Every 1st and 3rd Tuesday at 01:00 PM EDT >>> Bridge: https://bluejeans.com/486278655 >>> >>> Gluster-devel mailing list >>> Gluster-devel@gluster.org >>> https://lists.gluster.org/mailman/listinfo/gluster-devel >>> >>> ___ >> >> Community Meeting Calendar: >> >> APAC Schedule - >> Every 2nd and 4th Tuesday at 11:30 AM IST >> Bridge: https://bluejeans.com/836554017 >> >> NA/EMEA Schedule - >> Every 1st and 3rd Tuesday at 01:00 PM EDT >> Bridge: https://bluejeans.com/486278655 >> >> Gluster-devel mailing list >> Gluster-devel@gluster.org >> https://lists.gluster.org/mailman/listinfo/gluster-devel >> >> diff-option.patch Description: Binary data ___ Community Meeting Calendar: APAC Schedule - Every 2nd and 4th Tuesday at 11:30 AM IST Bridge: https://bluejeans.com/836554017 NA/EMEA Schedule - Every 1st and 3rd Tuesday at 01:00 PM EDT Bridge: https://bluejeans.com/486278655 Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Re-Compile glusterd1 and add it to the stack
Hello Vijay, there is a patch file attached. You can see the code there. I oriented myself here: https://review.gluster.org/#/c/glusterfs/+/18633/ As you can see there is no additional code in glusterd-volgen.c . Both glusterd-volgen.c and glusterd-volume.set.c will be compiled into glusterd.so . Its still the problem, that my new option is not available if I only re-compile glusterd.so . Compiling and using the whole RPMs is working It is not possible to re-compile glusterd.so ? Regards David Spisla Am Do., 11. Juli 2019 um 20:35 Uhr schrieb Vijay Bellur : > Hi David, > > If the option is related to a particular translator, you would need to add > that option in the options table of the translator and add code in > glusterd-volgen.c to generate that option in the volfiles. > > Would it be possible to share the code diff that you are trying out? > > Regards, > Vijay > > On Wed, Jul 10, 2019 at 3:11 AM David Spisla wrote: > >> Hello Gluster Devels, >> >> I add a custom volume option to glusterd-volume-set.c . I could build my >> own RPMs but I don't want this, I only want to add new compiled glusterd to >> the stack. I tried it out to copy glusterd.so to >> /usr/lib64/glusterfs/x.x/xlator/mgmt . After this glusterd is running >> normally and I can create volumes but in the vol files my new option is not >> there and if I want to start the volume it failed. >> >> It seems to be that I need to add some other files to the stack. Any idea? >> >> Regards >> David Spisla >> ___ >> >> Community Meeting Calendar: >> >> APAC Schedule - >> Every 2nd and 4th Tuesday at 11:30 AM IST >> Bridge: https://bluejeans.com/836554017 >> >> NA/EMEA Schedule - >> Every 1st and 3rd Tuesday at 01:00 PM EDT >> Bridge: https://bluejeans.com/486278655 >> >> Gluster-devel mailing list >> Gluster-devel@gluster.org >> https://lists.gluster.org/mailman/listinfo/gluster-devel >> >> ___ > > Community Meeting Calendar: > > APAC Schedule - > Every 2nd and 4th Tuesday at 11:30 AM IST > Bridge: https://bluejeans.com/836554017 > > NA/EMEA Schedule - > Every 1st and 3rd Tuesday at 01:00 PM EDT > Bridge: https://bluejeans.com/486278655 > > Gluster-devel mailing list > Gluster-devel@gluster.org > https://lists.gluster.org/mailman/listinfo/gluster-devel > > diff-option.patch Description: Binary data ___ Community Meeting Calendar: APAC Schedule - Every 2nd and 4th Tuesday at 11:30 AM IST Bridge: https://bluejeans.com/836554017 NA/EMEA Schedule - Every 1st and 3rd Tuesday at 01:00 PM EDT Bridge: https://bluejeans.com/486278655 Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] Re-Compile glusterd1 and add it to the stack
Hello Gluster Devels, I add a custom volume option to glusterd-volume-set.c . I could build my own RPMs but I don't want this, I only want to add new compiled glusterd to the stack. I tried it out to copy glusterd.so to /usr/lib64/glusterfs/x.x/xlator/mgmt . After this glusterd is running normally and I can create volumes but in the vol files my new option is not there and if I want to start the volume it failed. It seems to be that I need to add some other files to the stack. Any idea? Regards David Spisla ___ Community Meeting Calendar: APAC Schedule - Every 2nd and 4th Tuesday at 11:30 AM IST Bridge: https://bluejeans.com/836554017 NA/EMEA Schedule - Every 1st and 3rd Tuesday at 01:00 PM EDT Bridge: https://bluejeans.com/486278655 Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] Bitrot: Segmentation fault found in bitrot stub
Dear Gluster Devel, all informations are here: https://bugzilla.redhat.com/show_bug.cgi?id=1717757 Also a full backtrace is provided. The place of of the seg fault is located Regards David Spisla ___ Community Meeting Calendar: APAC Schedule - Every 2nd and 4th Tuesday at 11:30 AM IST Bridge: https://bluejeans.com/836554017 NA/EMEA Schedule - Every 1st and 3rd Tuesday at 01:00 PM EDT Bridge: https://bluejeans.com/486278655 Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] Improve stability between SMB/CTDB and Gluster (together with Samba Core Developer)
Dear Gluster Community, at the moment we are improving the stability of SMB/CTDB and Gluster. For this purpose we are working together with an advanced SAMBA Core Developer. He did some debugging but needs more information about Gluster Core Behaviour. *Would any of the Gluster Developer wants to have a online conference with him and me?* I would organize everything. In my opinion this is a good chance to improve stability of Glusterfs and this is at the moment one of the major issues in the Community. Regards David Spisla ___ Community Meeting Calendar: APAC Schedule - Every 2nd and 4th Tuesday at 11:30 AM IST Bridge: https://bluejeans.com/836554017 NA/EMEA Schedule - Every 1st and 3rd Tuesday at 01:00 PM EDT Bridge: https://bluejeans.com/486278655 Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Gluster version EOL date
Hello Abhisek, take a look on this: https://lists.gluster.org/pipermail/announce/2018-July/000103.html and this https://www.gluster.org/release-schedule/ Gluster 5.5 is a patch release. Gluster 5.x will be spported until v8.0 Regards David Spisla David Spisla Software Engineer david.spi...@iternity.com +49 761 59034852 iTernity GmbH Heinrich-von-Stephan-Str. 21 79100 Freiburg Deutschland Website Newsletter Support Portal iTernity GmbH. Geschäftsführer: Ralf Steinemann. Eingetragen beim Amtsgericht Freiburg: HRB-Nr. 701332. USt.Id DE242664311. [v01.023] Von: gluster-devel-boun...@gluster.org Im Auftrag von ABHISHEK PALIWAL Gesendet: Freitag, 22. März 2019 11:45 An: Gluster Devel Betreff: [Gluster-devel] Gluster version EOL date Hi, As per gluster community seems the latest version is 5.5. Could any one tell me what would be the EOL date for version 5.5? is it after 12 month of release date or what? -- Regards Abhishek Paliwal ___ Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] [Gluster-users] Replica 3 - how to replace failed node (peer)
Hello Martin, look here: https://access.redhat.com/documentation/en-us/red_hat_gluster_storage/3.4/pdf/administration_guide/Red_Hat_Gluster_Storage-3.4-Administration_Guide-en-US.pdf on page 324. There is a manual how to replace a brick in case of a hardware failure Regards David Spisla Am Mi., 10. Apr. 2019 um 11:42 Uhr schrieb Martin Toth : > Hi all, > > I am running replica 3 gluster with 3 bricks. One of my servers failed - > all disks are showing errors and raid is in fault state. > > Type: Replicate > Volume ID: 41d5c283-3a74-4af8-a55d-924447bfa59a > Status: Started > Number of Bricks: 1 x 3 = 3 > Transport-type: tcp > Bricks: > Brick1: node1.san:/tank/gluster/gv0imagestore/brick1 > Brick2: node2.san:/tank/gluster/gv0imagestore/brick1 <— this brick is down > Brick3: node3.san:/tank/gluster/gv0imagestore/brick1 > > So one of my bricks is totally failed (node2). It went down and all data > are lost (failed raid on node2). Now I am running only two bricks on 2 > servers out from 3. > This is really critical problem for us, we can lost all data. I want to > add new disks to node2, create new raid array on them and try to replace > failed brick on this node. > > What is the procedure of replacing Brick2 on node2, can someone advice? I > can’t find anything relevant in documentation. > > Thanks in advance, > Martin > ___ > Gluster-users mailing list > gluster-us...@gluster.org > https://lists.gluster.org/mailman/listinfo/gluster-users ___ Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] [Gluster-users] Bitrot: Time of signing depending on the file size???
Hello Amudhan, Am Fr., 1. März 2019 um 14:56 Uhr schrieb Amudhan P : > Hi David, > > Once after file write completes (fd closed) bitrot process will wait for > 120 seconds and if there no fd is opened for the file it will trigger the > signer process. > Yes, I already know this. But there is still the problem that a fd will no closed after open() as bigger s file is. See link to discussion. > > considering the signer, process start and end time file read speed was < > 250KB/s. > How can I measure this? > > To increase bitrot signer read speed need to modify the bitrot source file. > How can I do that? Regards David > > regards > Amudhan > > On Fri, Mar 1, 2019 at 5:49 PM David Spisla wrote: > >> Hello Amudhan, >> >> What does exactly mean "it takes < 250KB/s"? >> I figured out this discussion between you and Kotresh: >> https://lists.gluster.org/pipermail/gluster-users/2016-September/028354.html >> Kotresh mentioned there that the problem is because for some files fd >> process are still up in the brick process list. Bitrot signer can only sign >> a file if the fd is closed. And according to my observations it seems to be >> that as bigger a file is as longer the fd is still up. I could verify this >> with a 500MiB file and some smaller files. After a specific time only the >> fd for the 500MiB was up and the file still had no signature, for the >> smaller files there were no fds and they already had a signature. >> >> Does anybody know what is the reason for this? For me it looks loke a >> bug. >> >> Regards >> David >> >> Am Fr., 1. März 2019 um 08:58 Uhr schrieb Amudhan P > >: >> >>> Hi David, >>> >>> I have also tested the bitrot signature process by default it takes < >>> 250 KB/s. >>> >>> regards >>> Amudhan P >>> >>> >>> On Fri, Mar 1, 2019 at 1:19 PM David Spisla wrote: >>> >>>> Hello folks, >>>> >>>> I did some observations concerning the bitrot daemon. It seems to be >>>> that the bitrot signer is signing files depending on file size. I copied >>>> files with different sizes into a volume and I was wonderung because the >>>> files get their signature not the same time (I keep the expiry time default >>>> with 120). Here are some examples: >>>> >>>> 300 KB file ~2-3 m >>>> 70 MB file ~ 40 m >>>> 115 MB file ~ 1 Sh >>>> 800 MB file ~ 4,5 h >>>> >>>> What is the expected behaviour here? >>>> Why does it take so long to sign a 800MB file? >>>> What about 500GB or 1TB? >>>> Is there a way to speed up the sign process? >>>> >>>> My ambition is to understand this observation >>>> >>>> Regards >>>> David Spisla >>>> ___ >>>> Gluster-users mailing list >>>> gluster-us...@gluster.org >>>> https://lists.gluster.org/mailman/listinfo/gluster-users >>> >>> ___ Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] [Gluster-users] Bitrot: Time of signing depending on the file size???
Hello Amudhan, What does exactly mean "it takes < 250KB/s"? I figured out this discussion between you and Kotresh: https://lists.gluster.org/pipermail/gluster-users/2016-September/028354.html Kotresh mentioned there that the problem is because for some files fd process are still up in the brick process list. Bitrot signer can only sign a file if the fd is closed. And according to my observations it seems to be that as bigger a file is as longer the fd is still up. I could verify this with a 500MiB file and some smaller files. After a specific time only the fd for the 500MiB was up and the file still had no signature, for the smaller files there were no fds and they already had a signature. Does anybody know what is the reason for this? For me it looks loke a bug. Regards David Am Fr., 1. März 2019 um 08:58 Uhr schrieb Amudhan P : > Hi David, > > I have also tested the bitrot signature process by default it takes < 250 > KB/s. > > regards > Amudhan P > > > On Fri, Mar 1, 2019 at 1:19 PM David Spisla wrote: > >> Hello folks, >> >> I did some observations concerning the bitrot daemon. It seems to be that >> the bitrot signer is signing files depending on file size. I copied files >> with different sizes into a volume and I was wonderung because the files >> get their signature not the same time (I keep the expiry time default with >> 120). Here are some examples: >> >> 300 KB file ~2-3 m >> 70 MB file ~ 40 m >> 115 MB file ~ 1 Sh >> 800 MB file ~ 4,5 h >> >> What is the expected behaviour here? >> Why does it take so long to sign a 800MB file? >> What about 500GB or 1TB? >> Is there a way to speed up the sign process? >> >> My ambition is to understand this observation >> >> Regards >> David Spisla >> ___ >> Gluster-users mailing list >> gluster-us...@gluster.org >> https://lists.gluster.org/mailman/listinfo/gluster-users > > ___ Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] Bitrot: Time of signing depending on the file size???
Hello folks, I did some observations concerning the bitrot daemon. It seems to be that the bitrot signer is signing files depending on file size. I copied files with different sizes into a volume and I was wonderung because the files get their signature not the same time (I keep the expiry time default with 120). Here are some examples: 300 KB file ~2-3 m 70 MB file ~ 40 m 115 MB file ~ 1 Sh 800 MB file ~ 4,5 h What is the expected behaviour here? Why does it take so long to sign a 800MB file? What about 500GB or 1TB? Is there a way to speed up the sign process? My ambition is to understand this observation Regards David Spisla ___ Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] md-cache: May bug found in md-cache.c
Hello Amar,
it should be done. Thank you for the explanation
Regards
David
Von: Amar Tumballi Suryanarayan
Gesendet: Mittwoch, 20. Februar 2019 14:55
An: David Spisla
Cc: Gluster Devel
Betreff: Re: [Gluster-devel] md-cache: May bug found in md-cache.c
Hi David,
https://docs.gluster.org/en/latest/Developer-guide/Backport-Guidelines/ gives
more details about it.
But easiest is to go to your patch (https://review.gluster.org/22234), and then
click on 'Cherry Pick' button. In the pop-up, 'branch:' field, give 'release-6'
and Submit. If you want it in release-5 branch too, repeat the same, with
branch being 'release-5'. Siimlarly we need 'clone-of' bug for both the
branches (the original bug used in patch is for master branch).
That should be it. Rest, we can take care.
Thanks a lot!
Regards,
Amar
On Wed, Feb 20, 2019 at 6:58 PM David Spisla
mailto:david.spi...@iternity.com>> wrote:
Hello Amar,
no problem. How can I do that? Can you please tell me the procedure?
Regards
David
Von: Amar Tumballi Suryanarayan
mailto:atumb...@redhat.com>>
Gesendet: Mittwoch, 20. Februar 2019 14:18
An: David Spisla mailto:spisl...@gmail.com>>
Cc: Gluster Devel mailto:gluster-devel@gluster.org>>
Betreff: Re: [Gluster-devel] md-cache: May bug found in md-cache.c
Hi David,
Thanks for the patch, it got merged in master now. Can you please post it into
release branches, so we can take them in release-6, release-5 branch, so next
releases can have them.
Regards,
Amar
On Tue, Feb 19, 2019 at 8:49 PM David Spisla
mailto:spisl...@gmail.com>> wrote:
Hello,
I already open a bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1678726
There is also a link to a bug fix patch
Regards
David Spisla
Am Di., 19. Feb. 2019 um 13:07 Uhr schrieb David Spisla
mailto:spisl...@gmail.com>>:
Hi folks,
The 'struct md_cache' in md-cache.c uses int data types which are not in common
with the data types used in the 'struct iatt' in iatt.h . If one take a closer
look to the implementations one can see that the struct in md-cache.c uses
still the int data types like in the struct 'old_iatt' . This can lead to
unexpected side effects and some values of iatt maybe will not mapped
correctly. I would suggest to open a bug report. What do you think?
Additional info:
struct md_cache {
ia_prot_t md_prot;
uint32_t md_nlink;
uint32_t md_uid;
uint32_t md_gid;
uint32_t md_atime;
uint32_t md_atime_nsec;
uint32_t md_mtime;
uint32_t md_mtime_nsec;
uint32_t md_ctime;
uint32_t md_ctime_nsec;
uint64_t md_rdev;
uint64_t md_size;
uint64_t md_blocks;
uint64_t invalidation_time;
uint64_t generation;
dict_t *xattr;
char *linkname;
time_t ia_time;
time_t xa_time;
gf_boolean_t need_lookup;
gf_boolean_t valid;
gf_boolean_t gen_rollover;
gf_boolean_t invalidation_rollover;
gf_lock_t lock;
};
struct iatt {
uint64_t ia_flags;
uint64_t ia_ino; /* inode number */
uint64_t ia_dev; /* backing device ID */
uint64_t ia_rdev;/* device ID (if special file) */
uint64_t ia_size;/* file size in bytes */
uint32_t ia_nlink; /* Link count */
uint32_t ia_uid; /* user ID of owner */
uint32_t ia_gid; /* group ID of owner */
uint32_t ia_blksize; /* blocksize for filesystem I/O */
uint64_t ia_blocks; /* number of 512B blocks allocated */
int64_t ia_atime;/* last access time */
int64_t ia_mtime;/* last modification time */
int64_t ia_ctime;/* last status change time */
int64_t ia_btime;/* creation time. Fill using statx */
uint32_t ia_atime_nsec;
uint32_t ia_mtime_nsec;
uint32_t ia_ctime_nsec;
uint32_t ia_btime_nsec;
uint64_t ia_attributes; /* chattr related:compressed, immutable,
* append only, encrypted etc.*/
uint64_t ia_attributes_mask; /* Mask for the attributes */
uuid_t ia_gfid;
ia_type_t ia_type; /* type of file */
ia_prot_t ia_prot; /* protection */
};
struct old_iatt {
uint64_t ia_ino; /* inode number */
uuid_t ia_gfid;
uint64_t ia_dev; /* backing device ID */
ia_type_t ia_type; /* type of file */
ia_prot_t ia_prot; /* protection */
uint32_t ia_nlink; /* Link count */
uint32_t ia_uid; /* user ID of owner */
uint32_t ia_gid; /* group ID of owner */
uint64_t ia_rdev;/* device ID (if special file) */
uint64_t ia_size;/* file size in bytes */
uint32_t ia_blksize; /* blocksize for filesystem I/O */
uint64_t ia_blocks; /* number of 512B blocks allocated */
uint32_t ia_atime; /* last access time */
uint32_t ia_atime_nsec;
uint32_t ia_mtime; /* last modification time */
uint32_t ia_mtime_nsec;
uint32_t ia_ctime; /* last status change time */
uint32_t ia_ctime_nsec;
};
___
Gluster-devel mailing list
Gluster-devel@gluster.
Re: [Gluster-devel] md-cache: May bug found in md-cache.c
Hello Amar,
no problem. How can I do that? Can you please tell me the procedure?
Regards
David
Von: Amar Tumballi Suryanarayan
Gesendet: Mittwoch, 20. Februar 2019 14:18
An: David Spisla
Cc: Gluster Devel
Betreff: Re: [Gluster-devel] md-cache: May bug found in md-cache.c
Hi David,
Thanks for the patch, it got merged in master now. Can you please post it into
release branches, so we can take them in release-6, release-5 branch, so next
releases can have them.
Regards,
Amar
On Tue, Feb 19, 2019 at 8:49 PM David Spisla
mailto:spisl...@gmail.com>> wrote:
Hello,
I already open a bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1678726
There is also a link to a bug fix patch
Regards
David Spisla
Am Di., 19. Feb. 2019 um 13:07 Uhr schrieb David Spisla
mailto:spisl...@gmail.com>>:
Hi folks,
The 'struct md_cache' in md-cache.c uses int data types which are not in common
with the data types used in the 'struct iatt' in iatt.h . If one take a closer
look to the implementations one can see that the struct in md-cache.c uses
still the int data types like in the struct 'old_iatt' . This can lead to
unexpected side effects and some values of iatt maybe will not mapped
correctly. I would suggest to open a bug report. What do you think?
Additional info:
struct md_cache {
ia_prot_t md_prot;
uint32_t md_nlink;
uint32_t md_uid;
uint32_t md_gid;
uint32_t md_atime;
uint32_t md_atime_nsec;
uint32_t md_mtime;
uint32_t md_mtime_nsec;
uint32_t md_ctime;
uint32_t md_ctime_nsec;
uint64_t md_rdev;
uint64_t md_size;
uint64_t md_blocks;
uint64_t invalidation_time;
uint64_t generation;
dict_t *xattr;
char *linkname;
time_t ia_time;
time_t xa_time;
gf_boolean_t need_lookup;
gf_boolean_t valid;
gf_boolean_t gen_rollover;
gf_boolean_t invalidation_rollover;
gf_lock_t lock;
};
struct iatt {
uint64_t ia_flags;
uint64_t ia_ino; /* inode number */
uint64_t ia_dev; /* backing device ID */
uint64_t ia_rdev;/* device ID (if special file) */
uint64_t ia_size;/* file size in bytes */
uint32_t ia_nlink; /* Link count */
uint32_t ia_uid; /* user ID of owner */
uint32_t ia_gid; /* group ID of owner */
uint32_t ia_blksize; /* blocksize for filesystem I/O */
uint64_t ia_blocks; /* number of 512B blocks allocated */
int64_t ia_atime;/* last access time */
int64_t ia_mtime;/* last modification time */
int64_t ia_ctime;/* last status change time */
int64_t ia_btime;/* creation time. Fill using statx */
uint32_t ia_atime_nsec;
uint32_t ia_mtime_nsec;
uint32_t ia_ctime_nsec;
uint32_t ia_btime_nsec;
uint64_t ia_attributes; /* chattr related:compressed, immutable,
* append only, encrypted etc.*/
uint64_t ia_attributes_mask; /* Mask for the attributes */
uuid_t ia_gfid;
ia_type_t ia_type; /* type of file */
ia_prot_t ia_prot; /* protection */
};
struct old_iatt {
uint64_t ia_ino; /* inode number */
uuid_t ia_gfid;
uint64_t ia_dev; /* backing device ID */
ia_type_t ia_type; /* type of file */
ia_prot_t ia_prot; /* protection */
uint32_t ia_nlink; /* Link count */
uint32_t ia_uid; /* user ID of owner */
uint32_t ia_gid; /* group ID of owner */
uint64_t ia_rdev;/* device ID (if special file) */
uint64_t ia_size;/* file size in bytes */
uint32_t ia_blksize; /* blocksize for filesystem I/O */
uint64_t ia_blocks; /* number of 512B blocks allocated */
uint32_t ia_atime; /* last access time */
uint32_t ia_atime_nsec;
uint32_t ia_mtime; /* last modification time */
uint32_t ia_mtime_nsec;
uint32_t ia_ctime; /* last status change time */
uint32_t ia_ctime_nsec;
};
___
Gluster-devel mailing list
Gluster-devel@gluster.org<mailto:Gluster-devel@gluster.org>
https://lists.gluster.org/mailman/listinfo/gluster-devel
--
Amar Tumballi (amarts)
___
Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] md-cache: May bug found in md-cache.c
Hello,
I already open a bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1678726
There is also a link to a bug fix patch
Regards
David Spisla
Am Di., 19. Feb. 2019 um 13:07 Uhr schrieb David Spisla :
> Hi folks,
>
> The 'struct md_cache' in md-cache.c uses int data types which are not in
> common with the data types used in the 'struct iatt' in iatt.h . If one
> take a closer look to the implementations one can see that the struct in
> md-cache.c uses still the int data types like in the struct 'old_iatt' .
> This can lead to unexpected side effects and some values of iatt maybe will
> not mapped correctly. I would suggest to open a bug report. What do you
> think?
>
> Additional info:
>
> struct md_cache {
> ia_prot_t md_prot;
> uint32_t md_nlink;
> uint32_t md_uid;
> uint32_t md_gid;
> uint32_t md_atime;
> uint32_t md_atime_nsec;
> uint32_t md_mtime;
> uint32_t md_mtime_nsec;
> uint32_t md_ctime;
> uint32_t md_ctime_nsec;
> uint64_t md_rdev;
> uint64_t md_size;
> uint64_t md_blocks;
> uint64_t invalidation_time;
> uint64_t generation;
> dict_t *xattr;
> char *linkname;
> time_t ia_time;
> time_t xa_time;
> gf_boolean_t need_lookup;
> gf_boolean_t valid;
> gf_boolean_t gen_rollover;
> gf_boolean_t invalidation_rollover;
> gf_lock_t lock;
> };
>
> struct iatt {
> uint64_t ia_flags;
> uint64_t ia_ino; /* inode number */
> uint64_t ia_dev; /* backing device ID */
> uint64_t ia_rdev;/* device ID (if special file) */
> uint64_t ia_size;/* file size in bytes */
> uint32_t ia_nlink; /* Link count */
> uint32_t ia_uid; /* user ID of owner */
> uint32_t ia_gid; /* group ID of owner */
> uint32_t ia_blksize; /* blocksize for filesystem I/O */
> uint64_t ia_blocks; /* number of 512B blocks allocated */
> int64_t ia_atime;/* last access time */
> int64_t ia_mtime;/* last modification time */
> int64_t ia_ctime;/* last status change time */
> int64_t ia_btime;/* creation time. Fill using statx */
> uint32_t ia_atime_nsec;
> uint32_t ia_mtime_nsec;
> uint32_t ia_ctime_nsec;
> uint32_t ia_btime_nsec;
> uint64_t ia_attributes; /* chattr related:compressed, immutable,
> * append only, encrypted etc.*/
> uint64_t ia_attributes_mask; /* Mask for the attributes */
>
> uuid_t ia_gfid;
> ia_type_t ia_type; /* type of file */
> ia_prot_t ia_prot; /* protection */
> };
>
> struct old_iatt {
> uint64_t ia_ino; /* inode number */
> uuid_t ia_gfid;
> uint64_t ia_dev; /* backing device ID */
> ia_type_t ia_type; /* type of file */
> ia_prot_t ia_prot; /* protection */
> uint32_t ia_nlink; /* Link count */
> uint32_t ia_uid; /* user ID of owner */
> uint32_t ia_gid; /* group ID of owner */
> uint64_t ia_rdev;/* device ID (if special file) */
> uint64_t ia_size;/* file size in bytes */
> uint32_t ia_blksize; /* blocksize for filesystem I/O */
> uint64_t ia_blocks; /* number of 512B blocks allocated */
> uint32_t ia_atime; /* last access time */
> uint32_t ia_atime_nsec;
> uint32_t ia_mtime; /* last modification time */
> uint32_t ia_mtime_nsec;
> uint32_t ia_ctime; /* last status change time */
> uint32_t ia_ctime_nsec;
> };
>
___
Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] md-cache: May bug found in md-cache.c
Hi folks,
The 'struct md_cache' in md-cache.c uses int data types which are not in
common with the data types used in the 'struct iatt' in iatt.h . If one
take a closer look to the implementations one can see that the struct in
md-cache.c uses still the int data types like in the struct 'old_iatt' .
This can lead to unexpected side effects and some values of iatt maybe will
not mapped correctly. I would suggest to open a bug report. What do you
think?
Additional info:
struct md_cache {
ia_prot_t md_prot;
uint32_t md_nlink;
uint32_t md_uid;
uint32_t md_gid;
uint32_t md_atime;
uint32_t md_atime_nsec;
uint32_t md_mtime;
uint32_t md_mtime_nsec;
uint32_t md_ctime;
uint32_t md_ctime_nsec;
uint64_t md_rdev;
uint64_t md_size;
uint64_t md_blocks;
uint64_t invalidation_time;
uint64_t generation;
dict_t *xattr;
char *linkname;
time_t ia_time;
time_t xa_time;
gf_boolean_t need_lookup;
gf_boolean_t valid;
gf_boolean_t gen_rollover;
gf_boolean_t invalidation_rollover;
gf_lock_t lock;
};
struct iatt {
uint64_t ia_flags;
uint64_t ia_ino; /* inode number */
uint64_t ia_dev; /* backing device ID */
uint64_t ia_rdev;/* device ID (if special file) */
uint64_t ia_size;/* file size in bytes */
uint32_t ia_nlink; /* Link count */
uint32_t ia_uid; /* user ID of owner */
uint32_t ia_gid; /* group ID of owner */
uint32_t ia_blksize; /* blocksize for filesystem I/O */
uint64_t ia_blocks; /* number of 512B blocks allocated */
int64_t ia_atime;/* last access time */
int64_t ia_mtime;/* last modification time */
int64_t ia_ctime;/* last status change time */
int64_t ia_btime;/* creation time. Fill using statx */
uint32_t ia_atime_nsec;
uint32_t ia_mtime_nsec;
uint32_t ia_ctime_nsec;
uint32_t ia_btime_nsec;
uint64_t ia_attributes; /* chattr related:compressed, immutable,
* append only, encrypted etc.*/
uint64_t ia_attributes_mask; /* Mask for the attributes */
uuid_t ia_gfid;
ia_type_t ia_type; /* type of file */
ia_prot_t ia_prot; /* protection */
};
struct old_iatt {
uint64_t ia_ino; /* inode number */
uuid_t ia_gfid;
uint64_t ia_dev; /* backing device ID */
ia_type_t ia_type; /* type of file */
ia_prot_t ia_prot; /* protection */
uint32_t ia_nlink; /* Link count */
uint32_t ia_uid; /* user ID of owner */
uint32_t ia_gid; /* group ID of owner */
uint64_t ia_rdev;/* device ID (if special file) */
uint64_t ia_size;/* file size in bytes */
uint32_t ia_blksize; /* blocksize for filesystem I/O */
uint64_t ia_blocks; /* number of 512B blocks allocated */
uint32_t ia_atime; /* last access time */
uint32_t ia_atime_nsec;
uint32_t ia_mtime; /* last modification time */
uint32_t ia_mtime_nsec;
uint32_t ia_ctime; /* last status change time */
uint32_t ia_ctime_nsec;
};
___
Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] Heavy Bug in Bitrot Detection for v5.x
Dear Gluster Devels, please be aware of this heavy bug due to the bitrot detection. All details here: https://bugzilla.redhat.com/show_bug.cgi?id=1654370 There is a detailed reproduction. Pieces of 'scrub.log' is also there. Regards David Spisla ___ Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] Transfer file into WORM-State after FOP finished successfully
Hello folks, I am implementing some stuff with the WORM Xlator and I have the idea to transfer a file into the WORM state immediately after a FOP finished successfully. Example $ echo test >> test1.txt After the FOP finished the file should be automatically WORMed. But I would like to have an individual retention for each file, so I don't want to use Volume Level WORM function. At the moment autocommit is triggered after a specific period and the current FOP (e.g. write) would be blocked, but I want it to be my file WORMed immediately after the FOP (e.g. write) finished. Maybe some of you have an idea. It should be possible to get the information about the success of an FOP in one of cbk functions e.g if a file is created and worm-file-level enabled, create_cbk sets the xattr trusted.worm-file trusted.start_time for the file. So this should be possible after a write FOP succeed? Regards David Spisla ___ Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] Error while compiling Xlator manually with v5.0
Hi folks, I switched to the v5.0 tag and want to compile the worm xlator manually on my CentOS7 machine. Below there is following error while compiling worm.c: *gcc -fPIC -Wall -O0 -g -DHAVE_CONFIG_H -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DGF_LINUX_HOST_OS -I../../../.. -I../../../../contrib/uuid -I../../../../libglusterfs/src -I../../../../rpc/xdr/src -I../../../../xlators/lib/src -c -o worm.o worm.cIn file included from ../../../../libglusterfs/src/glusterfs.h:54:0, from ../../../../libglusterfs/src/common-utils.h:42, from ../../../../libglusterfs/src/circ-buff.h:14, from ../../../../libglusterfs/src/event-history.h:15, from ../../../../libglusterfs/src/xlator.h:18, from worm.c:10:../../../../libglusterfs/src/atomic.h:94:25: error: expected specifier-qualifier-list before ‘GF_ATOMIC_SIZE_SIZEOF_LONG’ GF_ATOMIC_MACRO(GF_ATOMIC_SIZE_, _size); \ ^../../../../libglusterfs/src/atomic.h:20:35: note: in definition of macro ‘GF_ATOMIC_MACRO_1’ #define GF_ATOMIC_MACRO_1(_macro) _macro ^../../../../libglusterfs/src/atomic.h:94:9: note: in expansion of macro ‘GF_ATOMIC_MACRO’ GF_ATOMIC_MACRO(GF_ATOMIC_SIZE_, _size); \ ^../../../../libglusterfs/src/atomic.h:103:1: note: in expansion of macro ‘GF_ATOMIC_TYPE’ GF_ATOMIC_TYPE(SIZEOF_LONG, intptr); /* gf_atomic_intptr_t */ ^../../../../libglusterfs/src/atomic.h:94:25: error: expected specifier-qualifier-list before ‘GF_ATOMIC_SIZE_SIZEOF_LONG’ GF_ATOMIC_MACRO(GF_ATOMIC_SIZE_, _size); \ ^../../../../libglusterfs/src/atomic.h:20:35: note: in definition of macro ‘GF_ATOMIC_MACRO_1’ #define GF_ATOMIC_MACRO_1(_macro) _macro ^../../../../libglusterfs/src/atomic.h:94:9: note: in expansion of macro ‘GF_ATOMIC_MACRO’ GF_ATOMIC_MACRO(GF_ATOMIC_SIZE_, _size); \ ^../../../../libglusterfs/src/atomic.h:108:1: note: in expansion of macro ‘GF_ATOMIC_TYPE’ GF_ATOMIC_TYPE(SIZEOF_LONG, uintptr); /* gf_atomic_uintptr_t */ ^make: *** [worm.o] Error 1* I am using this Makefile to compile the xlator manually: *# Change these to match your source code.TARGET = worm.soOBJECTS = worm.o worm-helper.o read-only-common.o \ $(GLFS_SRC)/contrib/uuid/copy.o \ $(GLFS_SRC)/xlators/lib/src/xlator_helper.o# Change these to match your environment.GLFS_SRC = ../../../..GLFS_LIB = /usr/lib64HOST_OS = GF_LINUX_HOST_OSCC=gccCFLAGS = -fPIC -Wall -O0 -g \ -DHAVE_CONFIG_H -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE \ -D$(HOST_OS) -I$(GLFS_SRC) -I$(GLFS_SRC)/contrib/uuid \ -I$(GLFS_SRC)/libglusterfs/src -I$(GLFS_SRC)/rpc/xdr/src \ -I$(GLFS_SRC)/xlators/lib/srcLDFLAGS = -shared -nostartfiles -L$(GLFS_LIB)LIBS = -lpthreadbuild: $(TARGET)$(TARGET): $(OBJECTS)$(CC) $(LDFLAGS) -o $(TARGET) $(OBJECTS) $(LIBS)* BEfore I compiling it, I do autogen, configure and make to prepare the Source Tree. Does I need to define more compile flags for the CFLAGS variable? I really don't know why the error above occurs. Compiling it with v4.1.5 succeed. Regards David Spisla ___ Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Compiling GLFS Source Tree under SLES15
Hello Kaleb, thank you for the clarification. Below one more short question... Am Di., 16. Okt. 2018 um 15:48 Uhr schrieb Kaleb S. KEITHLEY < kkeit...@redhat.com>: > On 10/16/18 9:30 AM, David Spisla wrote: > > Hello Kaleb, > > I've heard that you are responsible building Gluster RPMs for SUSE. > > At the moment I am working with SLES15 and do some xlator experiments. > > Therefore I am compiling the Source Tree to get all dependencies to > > compile some xlators manually. > > > > Is there any recommendation from the Gluster community to compile > > options under SUSE? > > I use at the moment: > > > > ./autogen.sh > > ./configure --without-libtirpc > > make > > > The rpm .spec I use for sles-15 is > > https://github.com/gluster/glusterfs-suse/blob/sles15-glusterfs-4.1/glusterfs.spec > > which is similar to that. > In this spec file you are using --enable-gnfs for configure (line 153). Well, I don't need this. But what about --disable-static ??? What is the reason for this? Regards David > > IMO you should not be using --without-libtirpc on newer distribution > releases like sles-15. > > > > > with gcc version 7.3.1. There is a file attached wicht the output of the > > build process. In the autogen.sh > > part there is warning concerning 'subdir-objects' and in the make part a > > lot of 'warnings'. Do you think this > > could be a problem? > > No, those warnings are benign AFAICT. > > -- > > Kaleb > ___ Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Compile Xlator manually with lib 'glusterfs'
Am Mi., 10. Okt. 2018 um 13:31 Uhr schrieb Amar Tumballi < atumb...@redhat.com>: > > > On Wed, Oct 10, 2018 at 4:43 PM David Spisla wrote: > >> Hi folks, >> I am trying some stuff with xlator compiling and at the moment I use a >> Makefile according to this manual: >> https://github.com/gluster/glusterfs/blob/master/doc/developer-guide/translator-development.md#this-time-for-real >> >> > While this gives a great details about translator developments, it may not > be up-to-date! Will get to fixing that! > I am looking forward for this! > > >> There is a Lib called 'glusterfs' which is used by the Linker to create >> the so file. This refers to a package 'glusterfs-api-devel' which has to be >> installed when using that Lib in the Makefile. One will have a folder >> /usr/include/glusterfs which contains a lot of Header files from the >> Gluster Source. >> >> In my opinion all the Header files inside there are also in the GLFS >> Source Tree and one doesn't need that library to compile xlators to so >> files. If I remove that library in the Makefile the compilation succeed and >> the xlator is running correctly. >> >> If I want to compile a xlator without the GLFS Source Tree by using only >> that 'glusterfs-api-devel' the compiler misses a lot of sources. >> >> But what is the meaning of that library now? Is the manual linked above >> outdated? >> At the moment I prefer not using that 'glusterfs' library and compile >> only from the GLFS Soruce Tree. >> >> > Two questions: > > Are you looking at developing a translator outside of glusterfs tree? like > mentioned @ https://bugzilla.redhat.com/show_bug.cgi?id=1636297 ? > Nice project. I am looking for this option! But it should be a solution without installing global packages, something like a minimal source tree Regards David > > Or do you want to add a translator to glusterfs source tree? Then I > recommend having a look at > https://github.com/gluster/glusterfs/tree/master/xlators/playground/template/src > > -Amar > > >> Regards >> David Spisla >> >> >> >> ___ >> Gluster-devel mailing list >> Gluster-devel@gluster.org >> https://lists.gluster.org/mailman/listinfo/gluster-devel > > > > -- > Amar Tumballi (amarts) > ___ Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] Compile Xlator manually with lib 'glusterfs'
Hi folks, I am trying some stuff with xlator compiling and at the moment I use a Makefile according to this manual: https://github.com/gluster/glusterfs/blob/master/doc/developer-guide/translator-development.md#this-time-for-real There is a Lib called 'glusterfs' which is used by the Linker to create the so file. This refers to a package 'glusterfs-api-devel' which has to be installed when using that Lib in the Makefile. One will have a folder /usr/include/glusterfs which contains a lot of Header files from the Gluster Source. In my opinion all the Header files inside there are also in the GLFS Source Tree and one doesn't need that library to compile xlators to so files. If I remove that library in the Makefile the compilation succeed and the xlator is running correctly. If I want to compile a xlator without the GLFS Source Tree by using only that 'glusterfs-api-devel' the compiler misses a lot of sources. But what is the meaning of that library now? Is the manual linked above outdated? At the moment I prefer not using that 'glusterfs' library and compile only from the GLFS Soruce Tree. Regards David Spisla ___ Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] SLES15 packages for Gluster 4.1.1
Dear Gluster-Devels, 3 days ago packages for GLFS 4.1.1 were released for CentOS. But unfortunately packages for SLES 15 are still at 4.1.0. Is there a way to get packages for 4.1.1 under SLES15 soon? Regards, David Spisla ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Update md-cache after triggering FOP via syncop framework?
Hello Niels, yes, this seems to be a good idea. In a few hours I have to travel to an IT conference. So I will start to try your suggestion next week. Regards David 2018-06-05 11:44 GMT+02:00 Niels de Vos : > On Tue, Jun 05, 2018 at 11:04:00AM +0200, David Spisla wrote: > > Hello Niels, > > > > thank you. Now I understand this better. > > I am triggering the FOPs via syncop directly from the WORM Xlator which > is > > unfortunately below the upcall xlator. > > I don't have a separate xlator, so I am searching for a solution which is > > working inside of the WORM Xlator. > > E.g. the autocommit function of the WORM Xlator is using the syncop > > framework to change the atime > > of a file. I don't know if there is a difference between FOPs triggered > by > > syncop or by clients from outside. > > My guess is that there is no difference, but I am not sure. > > You can experiment with moving the WORM xlator in the .vol files of the > bricks before upcall, just restart the brick processes after editing the > config files. > > I can not immediately think of a reason why this would cause problems. > You could send a patch that explains your need and changes the location > of WORM (or upcall?) in the graph (see server_graph_table in > xlators/mgmt/glusterd/src/glusterd-volgen.c). > > Niels > > > > > > Regards > > David > > > > 2018-06-05 9:51 GMT+02:00 Niels de Vos : > > > > > On Mon, Jun 04, 2018 at 03:23:05PM +0200, David Spisla wrote: > > > > Dear Gluster-Devels, > > > > > > > > I'm currently using the syncop framework to trigger certain file > > > operations > > > > within the Server Translators stack. At the same time, file > attributes > > > such > > > > as file rights and timestamps are changed (atime, mtime). I noticed > that > > > > the md-cache does not get the changed attributes or only when the > upcall > > > > xlator is activated eg by a READDIR (executing " $ stat * "). > > > > However, I would find it cleaner if right after triggering a file > > > operation > > > > by the syncop framework that would update md-cache. Is there a way to > > > > programmatically do this within the Server Translators stack? > > > > > > Hi David, > > > > > > If you place your xlator above upcall, upcall should inform the clients > > > about the changed attributes. In case it is below upcall, the internal > > > FOPs can not be tracked by upcall. > > > > > > Upcall tracks all clients that have shown interest in a particular > > > inode. If that inode is modified, the callback on the brick stack will > > > trigger a cache-invalidation on the client. I do not think there should > > > be a difference between FOPs from other clients, or locally created > ones > > > through the syncop framework. > > > > > > In case this does not help or work, provide a little more details (.vol > > > file?). > > > > > > HTH, > > > Niels > > > > ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Update md-cache after triggering FOP via syncop framework?
Hello Niels, thank you. Now I understand this better. I am triggering the FOPs via syncop directly from the WORM Xlator which is unfortunately below the upcall xlator. I don't have a separate xlator, so I am searching for a solution which is working inside of the WORM Xlator. E.g. the autocommit function of the WORM Xlator is using the syncop framework to change the atime of a file. I don't know if there is a difference between FOPs triggered by syncop or by clients from outside. My guess is that there is no difference, but I am not sure. Regards David 2018-06-05 9:51 GMT+02:00 Niels de Vos : > On Mon, Jun 04, 2018 at 03:23:05PM +0200, David Spisla wrote: > > Dear Gluster-Devels, > > > > I'm currently using the syncop framework to trigger certain file > operations > > within the Server Translators stack. At the same time, file attributes > such > > as file rights and timestamps are changed (atime, mtime). I noticed that > > the md-cache does not get the changed attributes or only when the upcall > > xlator is activated eg by a READDIR (executing " $ stat * "). > > However, I would find it cleaner if right after triggering a file > operation > > by the syncop framework that would update md-cache. Is there a way to > > programmatically do this within the Server Translators stack? > > Hi David, > > If you place your xlator above upcall, upcall should inform the clients > about the changed attributes. In case it is below upcall, the internal > FOPs can not be tracked by upcall. > > Upcall tracks all clients that have shown interest in a particular > inode. If that inode is modified, the callback on the brick stack will > trigger a cache-invalidation on the client. I do not think there should > be a difference between FOPs from other clients, or locally created ones > through the syncop framework. > > In case this does not help or work, provide a little more details (.vol > file?). > > HTH, > Niels > ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] Update md-cache after triggering FOP via syncop framework?
Dear Gluster-Devels, I'm currently using the syncop framework to trigger certain file operations within the Server Translators stack. At the same time, file attributes such as file rights and timestamps are changed (atime, mtime). I noticed that the md-cache does not get the changed attributes or only when the upcall xlator is activated eg by a READDIR (executing " $ stat * "). However, I would find it cleaner if right after triggering a file operation by the syncop framework that would update md-cache. Is there a way to programmatically do this within the Server Translators stack? Regards David Spisla ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] Using syncop_readdir inside Xlator
Dear Gluster Devels,
I want to read all the entries in a DIR inside of a xlator. For this
purpose I use the syncop_readdir function which is also used in die
self-heal functionality for example.
Here is a piece of code from inside the worm_rename function:
fd_t *fd = NULL;
gf_dirent_t entries;
fd = fd_anonymous (oldloc->inode);
if (fd == NULL) {
gf_log (this->name, GF_LOG_ERROR, "fd creation
failed");
ret = -ENOMEM;
goto out;
}
INIT_LIST_HEAD ();
ret = syncop_readdir (this, fd, 131072, 0, , NULL,
NULL);
if (ret) {
gf_log (this->name, GF_LOG_ERROR, "failed getting
dir entries");
ret = -ENOMEM;
goto out;
}
The problem is, that I always get the Error: "failed getting dir entries" .
It seems to be that there is something wrong with the execution of that
function. Any ideas?
Regards
David Spisla
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Simulating some kind of "virtual file"
Hello Xavi, Von: Xavi Hernandez [mailto:jaher...@redhat.com] Gesendet: Donnerstag, 11. Januar 2018 10:51 An: David Spisla <david.spi...@iternity.com> Cc: Amar Tumballi <atumb...@redhat.com>; gluster-devel@gluster.org Betreff: Re: [Gluster-devel] Simulating some kind of "virtual file" Hi David, On Wed, Jan 10, 2018 at 3:24 PM, David Spisla <david.spi...@iternity.com<mailto:david.spi...@iternity.com>> wrote: Hello Amar, Xavi Von: Amar Tumballi [mailto:atumb...@redhat.com<mailto:atumb...@redhat.com>] Gesendet: Mittwoch, 10. Januar 2018 14:16 An: Xavi Hernandez <jaher...@redhat.com<mailto:jaher...@redhat.com>>; David Spisla <david.spi...@iternity.com<mailto:david.spi...@iternity.com>> Cc: gluster-devel@gluster.org<mailto:gluster-devel@gluster.org> Betreff: Re: [Gluster-devel] Simulating some kind of "virtual file" Check the files in $mountpoint/.meta/ directory. These are all virtual. And meta xlator gives a very good idea about how to handle virtual files (and directories). -Amar [David Spisla] Sounds good. Thank you On Wed, Jan 10, 2018 at 6:36 PM, Xavi Hernandez <jaher...@redhat.com<mailto:jaher...@redhat.com>> wrote: Hi David, On Wed, Jan 10, 2018 at 1:42 PM, David Spisla <david.spi...@iternity.com<mailto:david.spi...@iternity.com>> wrote: [David Spisla] I tried this: char *new_path = malloc(1+len_path-5); memcpy(new_path, loc->path, len_path-5); new_path[strlen(new_path)] = '\0'; loc->name = new_path + (len_path - len_name); First of all, you should always use memory allocation functions from gluster. This includes GF_MALLOC(), gf_strdup(), gf_asprintf() and several other variants. You can look at libglusterfs/src/mem-pool.h to see all available options. The second problem I see is that memcpy() doesn't write a terminating null character, so when you compute strlen() afterwards, it will return invalid length, or even try to access invalid memory, causing a crash. You should do something like this (assuming both loc->path and loc->name are not NULL and skipping many necessary checks): len_path = strlen(loc->path); len_name = strlen(loc->name); new_path = GF_MALLOC(len_path - 4, gf_common_mt_char); memcpy(new_path, loc->path, len_path - 5); new_path[len_path - 5] = 0; loc->name = new_path + len_path - len_name; This should work fine. Xavi [David Spisla] Yes, this worls fine. Thank you . By the way, is there a way inside gluster xlator to get access to xattr or attr of a file. In the lookup function there is only the struct loc, but I am missing there the files gfid. It seems to be null always. I could use syncop_getxattr() with the parameter loc, but the gfid is missing. Can I get the gfid if I have only loc->path and loc-> name? It is like a conversion from files path to files gfid. One of the main purposes of the 'lookup' fop is to resolve a given path to an existing gfid, so you won't find any gfid in the lookup request (unless it's a revalidate request). You need to look at the response (cbk) of the lookup to get the real gfid. If the request succeeds, you can find the gfid in buf->ia_gfid of the lookup callback. Other fops that receive a loc_t structure are normally called after a successful lookup, so loc->gfid and/or loc->inode->gfid should be set (unfortunately there isn't an homogeneous management of loc_t structures by xlators, so not always both fields are set). You can also request additional xattrs in the lookup request by adding them to the xdata dictionary. Their values will be returned in the xdata argument of the lookup callback. Xavi [David Spisla] Ok, so there is no chance to get that gfid in an initial lookup. In the request, no. Only revalidate lookups will include the gfid, but the initial one will only contain a path. You need to look at the answer (in the cbk of lookup) to determine the gfid. Another problem seems to be that there is no loc parameter in lookup_cbk function. I have the buf->gfid and inode, but there is no loc with the path and name oft he file. In this case, you need to save the path (or the entire loc if you prefer) when you receive the lookup request and pass it to the cbk to be used there. To do so you need to create a data structure that needs to be allocated and filled when the lookup request is received. Then you can pass this structure to the cbk in two ways (basically): 1. Attach it to frame->local. You can access it later from cbk using frame->local. 2. Pass it as a "cookie" in STACK_WIND_COOKIE(). You can access it from cbk using the 'cookie' argument. [David Spisla] Yes, first I tried to store it as loc_t* in an additional variable in read_only_priv_t. This also worked, but your solution seems to be more cleaner. It is better to use the existing infrastructure. I prefer using solution 1. Doing frame->local = loc in lookup and get i
Re: [Gluster-devel] Simulating some kind of "virtual file"
Hello Amar, Xavi Von: Amar Tumballi [mailto:atumb...@redhat.com] Gesendet: Mittwoch, 10. Januar 2018 14:16 An: Xavi Hernandez <jaher...@redhat.com>; David Spisla <david.spi...@iternity.com> Cc: gluster-devel@gluster.org Betreff: Re: [Gluster-devel] Simulating some kind of "virtual file" Check the files in $mountpoint/.meta/ directory. These are all virtual. And meta xlator gives a very good idea about how to handle virtual files (and directories). -Amar [David Spisla] Sounds good. Thank you On Wed, Jan 10, 2018 at 6:36 PM, Xavi Hernandez <jaher...@redhat.com<mailto:jaher...@redhat.com>> wrote: Hi David, On Wed, Jan 10, 2018 at 1:42 PM, David Spisla <david.spi...@iternity.com<mailto:david.spi...@iternity.com>> wrote: [David Spisla] I tried this: char *new_path = malloc(1+len_path-5); memcpy(new_path, loc->path, len_path-5); new_path[strlen(new_path)] = '\0'; loc->name = new_path + (len_path - len_name); First of all, you should always use memory allocation functions from gluster. This includes GF_MALLOC(), gf_strdup(), gf_asprintf() and several other variants. You can look at libglusterfs/src/mem-pool.h to see all available options. The second problem I see is that memcpy() doesn't write a terminating null character, so when you compute strlen() afterwards, it will return invalid length, or even try to access invalid memory, causing a crash. You should do something like this (assuming both loc->path and loc->name are not NULL and skipping many necessary checks): len_path = strlen(loc->path); len_name = strlen(loc->name); new_path = GF_MALLOC(len_path - 4, gf_common_mt_char); memcpy(new_path, loc->path, len_path - 5); new_path[len_path - 5] = 0; loc->name = new_path + len_path - len_name; This should work fine. Xavi [David Spisla] Yes, this worls fine. Thank you . By the way, is there a way inside gluster xlator to get access to xattr or attr of a file. In the lookup function there is only the struct loc, but I am missing there the files gfid. It seems to be null always. I could use syncop_getxattr() with the parameter loc, but the gfid is missing. Can I get the gfid if I have only loc->path and loc-> name? It is like a conversion from files path to files gfid. One of the main purposes of the 'lookup' fop is to resolve a given path to an existing gfid, so you won't find any gfid in the lookup request (unless it's a revalidate request). You need to look at the response (cbk) of the lookup to get the real gfid. If the request succeeds, you can find the gfid in buf->ia_gfid of the lookup callback. Other fops that receive a loc_t structure are normally called after a successful lookup, so loc->gfid and/or loc->inode->gfid should be set (unfortunately there isn't an homogeneous management of loc_t structures by xlators, so not always both fields are set). You can also request additional xattrs in the lookup request by adding them to the xdata dictionary. Their values will be returned in the xdata argument of the lookup callback. Xavi [David Spisla] Ok, so there is no chance to get that gfid in an initial lookup. Another problem seems to be that there is no loc parameter in lookup_cbk function. I have the buf->gfid and inode, but there is no loc with the path and name oft he file. I I want to use syncop_getxattr but I have no loc as parameter. Can I get a loc struct with the gfid? David ___ Gluster-devel mailing list Gluster-devel@gluster.org<mailto:Gluster-devel@gluster.org> http://lists.gluster.org/mailman/listinfo/gluster-devel -- Amar Tumballi (amarts) ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Simulating some kind of "virtual file"
Hello Xavier, now adding gluster-devel Von: Xavi Hernandez [mailto:jaher...@redhat.com] Gesendet: Dienstag, 9. Januar 2018 23:02 An: David Spisla <david.spi...@iternity.com> Cc: gluster-devel@gluster.org Betreff: Re: [Gluster-devel] Simulating some kind of "virtual file" Hi David, adding again gluster-devel. On Tue, Jan 9, 2018 at 4:15 PM, David Spisla <david.spi...@iternity.com<mailto:david.spi...@iternity.com>> wrote: Hello Xavi, Von: Xavi Hernandez [mailto:jaher...@redhat.com<mailto:jaher...@redhat.com>] Gesendet: Dienstag, 9. Januar 2018 09:48 An: David Spisla <spisl...@googlemail.com<mailto:spisl...@googlemail.com>> Cc: gluster-devel@gluster.org<mailto:gluster-devel@gluster.org> Betreff: Re: [Gluster-devel] Simulating some kind of "virtual file" Hi David, On Tue, Jan 9, 2018 at 9:09 AM, David Spisla <spisl...@googlemail.com<mailto:spisl...@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. [David Spisla] Yes, this is a very good hint. $ 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. [David Spisla] At the moment I do it in the worm xlator. It seems to be no problem. 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). [David Spisla] I tried this: char *new_path = malloc(1+len_path-5); memcpy(new_path, loc->path, len_path-5); new_path[strlen(new_path)] = '\0'; loc->name = new_path + (len_path - len_name); First of all, you should always use memory allocation functions from gluster. This includes GF_MALLOC(), gf_strdup(), gf_asprintf() and several other variants. You can look at libglusterfs/src/mem-pool.h to see all available options. The second problem I see is that memcpy() doesn't write a terminating null character, so when you compute strlen() afterwards, it will return invalid length, or even try to access invalid memory, causing a crash. You should do something like this (assuming both loc->path and loc->name are not NULL and skipping many necessary checks): len_path = strlen(loc->path); len_name = strlen(loc->name); new_path = GF_MALLOC(len_path - 4, gf_common_mt_char); memcpy(new_path, loc->path, len_path - 5); new_path[len_path - 5] = 0; loc->name = new_path + len_path - len_name; This should work fine. Xavi [David Spisla] Yes, this worls fine. Thank you . By the way, is there a way inside gluster xlator to get access to xattr or attr of a file. In the lookup function there is only the struct loc, but I am
[Gluster-devel] Simulating some kind of "virtual file"
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). $ 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? 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. Any hints? Regards David Spisla ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] Translator issue: Change content of iovec
Dear GlusterDevels,
I am coding a translator which is changing the content of the iovec if a user
wants to read the content of the original file. Imagine you have a simple text
file with the content "hello".
If the user wants to read that file, my translator changes the content to "I am
the new content!!!". But at the moment my translator is not working perfectly.
Original Content -->"hello"
New content --> "I am the new content!!!"
If I read that file I get --> "I am "
It seems that there is still the old filesize allocated. I am looking for a way
to allocate a new size so that my new String will fit into that file.
I tried out several things, but without success. Maybe someone of you has an
idea. At the moment my translator is on the top of the client stack.
You find the source attached. I did all changes in --> stub_readv_cbk
Regards
David Spisla
/*
Author: David Spisla
*/
#include
#include
#include "glusterfs.h"
#include "xlator.h"
#include "logging.h"
#include "stub-mem-types.h"
#include
#include
#include
/*
* This is a test xlator to write and read a stub-file
* and extract informations about the path to
* the original file. This is just for testing
* issue, not for production use.
*/
int32_t
stub_readv_cbk (call_frame_t *frame,
void *cookie,
xlator_t *this,
int32_t op_ret,
int32_t op_errno,
struct iovec *vector,
int32_t count,
struct iatt *stbuf,
struct iobref *iobref, dict_t *xdata)
{
struct iovec *new_vec;
struct iobref *new_iobref;
iobref_clear (iobref);
char temp[] = "I am the new content!!!\n";
char *buf0 = "I am the new content!!!\n";
stbuf->ia_size = sizeof(temp);
new_vec = GF_CALLOC(1, sizeof(temp), gf_stub_mt_iovec);
struct iobuf *iobuf = NULL;
iobuf = iobuf_get2(this->ctx->iobuf_pool, sizeof(temp));
iobuf->ptr = buf0;
iobuf->free_ptr = buf0;
new_iobref = iobref_new();
iobref_add(new_iobref, iobuf);
new_vec[0].iov_base = buf0;
new_vec[0].iov_len = sizeof(temp);
STACK_UNWIND_STRICT (readv, frame, stbuf->ia_size, op_errno, new_vec,
count,
stbuf, new_iobref, xdata);
return 0;
}
int32_t
stub_readv (
call_frame_t *frame,
xlator_t *this,
fd_t * fd,
size_t size,
off_t offset,
uint32_t flags,
dict_t * xdata)
{
STACK_WIND (frame,
stub_readv_cbk,
FIRST_CHILD(this),
FIRST_CHILD(this)->fops->readv,
fd, size, offset, flags, xdata);
return 0;
}
int32_t
stub_writev (
call_frame_t *frame,
xlator_t *this,
fd_t * fd,
struct iovec * vector,
int32_t count,
off_t off,
uint32_t flags,
struct iobref * iobref,
dict_t * xdata)
{
STACK_WIND_TAIL (frame,
FIRST_CHILD(this), FIRST_CHILD(this)->fops->writev,
fd, vector, count, off, flags, iobref, xdata);
return 0;
}
int32_t
stub_lookup_cbk (call_frame_t *frame, void *cookie, xlator_t *this,
int32_t op_ret, int32_t op_errno, inode_t * inode,
struct iatt * buf,
dict_t * xdata,
struct iatt * postparent)
{
STACK_UNWIND_STRICT (lookup, frame, op_ret, op_errno,
inode, buf, xdata, postparent);
return 0;
}
int32_t
stub_lookup (
call_frame_t *frame,
xlator_t *this,
loc_t * loc,
dict_t * xdata)
{
STACK_WIND (frame, stub_lookup_cbk,
FIRST_CHILD(this), FIRST_CHILD(this)->fops->lookup,
loc, xdata);
return 0;
}
int32_t
init (xlator_t *this)
{
data_t *data = NULL;
if (!this->parents) {
gf_log (this->name, GF_LOG_WARNING,
"dangling volume. check volfile ");
}
gf_log ("stub", GF_LOG_DEBUG, "stub xlator loaded");
return 0;
}
void
fini (xlator_t *this)
{
this->private = NULL;
return;
}
struct xlator_fops fops = {
.readv= stub_readv,
.writev = stub_writev,
.lookup = stub_lookup
};
struct xlator_cbks cbks;
struct volume_options options[] = {
};
/*
Author: David Spisla
*/
#ifndef __STUB_MEM_TYPES_H__
#define __STUB_MEM_TYPES_H__
#include "mem-types.h"
enum gf_stub_mem_types_ {
gf_stub_mt_data,
gf_s
[Gluster-devel] Writing new Xlator and manipulate data
Hello Gluster-Devels,
actually I am writing my first xlator according to this tutorial:
https://github.com/gluster/glusterfs/blob/master/doc/developer-guide/translator-development.md
So I put the rot-13 Xlator and wrote my own stuff. My idea is to change the
iovec-content and put a new content in it.
My readv_cbk look like this:
int32_t
stub_iovec (xlator_t *this, struct iovec *vector, struct iobref *iobref, struct
iatt *stbuf, int count)
{
int i;
for (i = 0; i < count; i++) {
struct iobuf *iobuf = NULL;
iobuf = iobuf_get(this->ctx->iobuf_pool);
iobuf_unref(iobref->iobrefs[i]);
iobref = iobref_new();
iobref_add(iobref, iobuf);
char temp[] = "I am the manipulated content!!!\n";
char *buf0 = "I am the manipulated content!!!\n";
vector[i].iov_base = buf0;
vector[i].iov_len = sizeof(temp);
stbuf->ia_size = sizeof(temp);
return stbuf->ia_size;
}
}
int32_t
stub_readv_cbk (call_frame_t *frame,
void *cookie,
xlator_t *this,
int32_t op_ret,
int32_t op_errno,
struct iovec *vector,
int32_t count,
struct iatt *stbuf,
struct iobref *iobref, dict_t *xdata)
{
gf_log (this->name, GF_LOG_DEBUG, "Führe stub_readv_cbk aus!!!");
int32_t new_op_ret = stub_iovec(this, vector, iobref, stbuf, count);
STACK_UNWIND_STRICT (readv, frame, new_op_ret, op_errno, vector,
count,
stbuf, iobref, xdata);
return 0;
}
Ist not really working at all. If I have an original content like a simple
"orig" in a test.txt and change it to "manipulate",
the command "cat /mnt/gluster/test.txt" show me an "mani". The size if the
content did not changed.
Any idea about hat?
Regards
David
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel
