Re: [Gluster-devel] [Gluster-users] Gluster Volume mounted but not able to show the files from mount point

[ABHISHEK PALIWAL]

i am still facing this issue any suggestion

On Fri, May 27, 2016 at 10:48 AM, ABHISHEK PALIWAL 
wrote:

> any hint from the logs..
>
> On Thu, May 26, 2016 at 11:59 AM, ABHISHEK PALIWAL <
> abhishpali...@gmail.com> wrote:
>
>>
>>
>> On Thu, May 26, 2016 at 11:54 AM, Lindsay Mathieson <
>> lindsay.mathie...@gmail.com> wrote:
>>
>>> On 25 May 2016 at 20:25, ABHISHEK PALIWAL 
>>> wrote:
>>> > [2016-05-24 12:10:20.091267] E [MSGID: 113039]
>>> [posix.c:2570:posix_open]
>>> > 0-c_glusterfs-posix: open on
>>> >
>>> /opt/lvmdir/c2/brick/.glusterfs/fb/14/fb147cca-ec09-4259-9dfe-df883219e6a6,
>>> > flags: 2 [No such file or directory]
>>> > [2016-05-24 12:13:17.305773] E [MSGID: 113039]
>>> [posix.c:2570:posix_open]
>>> > 0-c_glusterfs-posix: open on
>>> >
>>> /opt/lvmdir/c2/brick/.glusterfs/fb/14/fb147cca-ec09-4259-9dfe-df883219e6a6,
>>> > flags: 2 [No such file or directory]
>>>
>>> does /opt/lvmdir/c2/brick contain anything? dies it have a .glusterfd
>>> dir?
>>>
>> Yes .glusterfs directory is present and /opt/lvmdir/c2/brick containing
>> files.
>>
>>>
>>> Could the underlying file system mount for that brick have failed?
>>>
>> mount is successful
>>
>> I have doubt on the following logs
>> [2016-05-24 10:40:34.177887] W [MSGID: 113006] [posix.c:3049:posix_flush]
>> 0-c_glusterfs-posix: pfd is NULL on fd=0x3fff8c003e4c [Operation not
>> permitted]
>> [2016-05-24 10:40:34.178022] E [MSGID: 115065]
>> [server-rpc-fops.c:1354:server_flush_cbk] 0-c_glusterfs-server: 3684: FLUSH
>> -2 (a5a5e596-e786-4f48-8f04-431712d98a6b) ==> (Operation not permitted)
>> [Operation not permitted]
>>
>> Like who will call this posix_flush and in which circumstances?
>>
>> Regards,
>> Abhishek
>>
>>>
>>>
>>> --
>>> Lindsay
>>>
>>
>>
>>
>>
>
>
> --
>
>
>
>
> Regards
> Abhishek Paliwal
>



-- 




Regards
Abhishek Paliwal
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Weekly Community Meeting - 01/June/2016

[Mohammed Rafi K C]

The meeting minutes for this weeks meeting are available at

Minutes:
https://meetbot.fedoraproject.org/gluster-meeting/2016-06-01/weekly_community_meeting_01june2016.2016-06-01-12.00.html
Minutes (text) :
https://meetbot.fedoraproject.org/gluster-meeting/2016-06-01/weekly_community_meeting_01june2016.2016-06-01-12.00.txt
Log:
https://meetbot.fedoraproject.org/gluster-meeting/2016-06-01/weekly_community_meeting_01june2016.2016-06-01-12.00.log.html

Meeting summary
---
* Rollcall  (rafi1, 12:00:58)

* Next weeks meeting host  (rafi1, 12:04:35)

* GlusterFS 4.0  (rafi1, 12:07:30)

* GlusterFS 3.8  (rafi1, 12:11:47)
  * HELP: needed to review the backport patches  (rafi1, 12:13:48)
  * LINK:

http://review.gluster.org/#/q/status:open+project:glusterfs+branch:release-3.8
(rafi1, 12:13:55)
  * requesting to feature owners to give their release notes here in
https://public.pad.fsfe.org/p/glusterfs-3.8-release-notes  (rafi1,
12:16:11)
  * LINK:

https://bugzilla.redhat.com/showdependencytree.cgi?id=glusterfs-3.8.0_resolved=1
(rafi1, 12:19:03)
  * LINK:

https://meetbot.fedoraproject.org/gluster-meeting/2016-05-18/weekly_community_meeting_18may2016.2016-05-18-12.06.log.html
(post-factum, 12:20:01)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1337130   (rafi1,
12:24:07)

* GlusterFS 3.7  (rafi1, 12:26:13)
  * tentative date for 3.7.12 is on June 9th  (rafi1, 12:30:11)

* GlusterFS 3.6  (rafi1, 12:30:25)
  * LINK:
http://www.gluster.org/pipermail/gluster-devel/2016-May/049677.html
(anoopcs, 12:30:38)
  * targeted release for next 3.6 version ie 3.6.10 will be around 26 of
this month  (rafi1, 12:37:42)

* GlusterFS 3.5  (rafi1, 12:38:04)

* NFS Ganesha  (rafi1, 12:39:32)

* Samba  (rafi1, 12:41:11)

* samba  (rafi1, 12:45:16)

* AI from last week  (rafi1, 12:48:48)

* kshlm/csim/nigelb to set up faux/pseudo user email for gerrit,
  bugzilla, github  (rafi1, 12:49:17)
  * ACTION: kshlm/csim to set up faux/pseudo user email for gerrit,
bugzilla, github  (rafi1, 12:52:27)

* aravinda/amye to check on some blog posts being distorted on
  blog.gluster.org, josferna's post in particular  (rafi1, 12:52:48)
  * ACTION: aravindavk/amye to check on some blog posts being distorted
on blog.gluster.org, josferna's post in particular  (rafi1,
12:54:47)

* hagarth to announce release strategy after getting inputs from amye
  (rafi1, 12:55:19)
  * LINK:
http://www.gluster.org/pipermail/gluster-devel/2016-May/049677.html
(rafi1, 12:55:44)

* kshlm to check with reported of 3.6 leaks on backport need  (rafi1,
  12:56:49)
  * ACTION: kshlm to check with reported of 3.6 leaks on backport need
(rafi1, 12:57:40)

* rastar to look at 3.6 builds failures on BSD  (rafi1, 12:57:51)
  * ACTION: rastar to look at 3.6 builds failures on BSD  (rafi1,
12:58:25)

* Open floor  (rafi1, 12:58:48)

Meeting ended at 13:01:04 UTC.




Action Items

* kshlm/csim to set up faux/pseudo user email for gerrit, bugzilla,
  github
* aravindavk/amye to check on some blog posts being distorted on
  blog.gluster.org, josferna's post in particular
* kshlm to check with reported of 3.6 leaks on backport need
* rastar to look at 3.6 builds failures on BSD




Action Items, by person
---
* **UNASSIGNED**
  * kshlm/csim to set up faux/pseudo user email for gerrit, bugzilla,
github
  * aravindavk/amye to check on some blog posts being distorted on
blog.gluster.org, josferna's post in particular
  * kshlm to check with reported of 3.6 leaks on backport need
  * rastar to look at 3.6 builds failures on BSD




People Present (lines said)
---
* rafi1 (96)
* jiffin (26)
* post-factum (18)
* kkeithley (6)
* anoopcs (4)
* olia (4)
* zodbot (3)
* nigelb (1)
* karthik___ (1)
* glusterbot (1)
* overclk (1)
* partner (1)
* rjoseph (1)





___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Huge VSZ (VIRT) usage by glustershd on dummy node

[Oleksandr Natalenko]

Also, I see lots of entries in pmap output:

===
7ef9ff8f3000  4K -   [ anon ]
7ef9ff8f4000   8192K rw---   [ anon ]
7efa000f4000  4K -   [ anon ]
7efa000f5000   8192K rw---   [ anon ]
===

If I sum them, I get the following:

===
# pmap 15109 | grep '[ anon ]' | grep 8192K | wc -l
9261
$ echo "9261*(8192+4)" | bc
75903156
===

Which is something like 70G+ I have got in VIRT.

06.06.2016 11:24, Oleksandr Natalenko написав:

Hello.

We use v3.7.11, replica 2 setup between 2 nodes + 1 dummy node for
keeping volumes metadata.

Now we observe huge VSZ (VIRT) usage by glustershd on dummy node:

===
root 15109  0.0 13.7 76552820 535272 ? Ssl  тра26   2:11
/usr/sbin/glusterfs -s localhost --volfile-id gluster/glustershd -p
/var/lib/glusterd/glustershd/run/glustershd.pid -l
/var/log/glusterfs/glustershd.log -S
/var/run/gluster/7848e17764dd4ba80f4623aecb91b07a.socket
--xlator-option
*replicate*.node-uuid=80bc95e1-2027-4a96-bb66-d9c8ade624d7
===

that is ~73G. RSS seems to be OK (~522M). Here is the statedump of
glustershd process: [1]

Also, here is sum of sizes, presented in statedump:

===
# cat /var/run/gluster/glusterdump.15109.dump.1465200139 | awk -F '='
'BEGIN {sum=0} /^size=/ {sum+=$2} END {print sum}'
353276406
===

That is ~337 MiB.

Also, here are VIRT values from 2 replica nodes:

===
root 24659  0.0  0.3 5645836 451796 ?  Ssl  тра24   3:28
/usr/sbin/glusterfs -s localhost --volfile-id gluster/glustershd -p
/var/lib/glusterd/glustershd/run/glustershd.pid -l
/var/log/glusterfs/glustershd.log -S
/var/run/gluster/44ec3f29003eccedf894865107d5db90.socket
--xlator-option
*replicate*.node-uuid=a19afcc2-e26c-43ce-bca6-d27dc1713e87
root 18312  0.0  0.3 6137500 477472 ?  Ssl  тра19   6:37
/usr/sbin/glusterfs -s localhost --volfile-id gluster/glustershd -p
/var/lib/glusterd/glustershd/run/glustershd.pid -l
/var/log/glusterfs/glustershd.log -S
/var/run/gluster/1670a3abbd1eea968126eb6f5be20322.socket
--xlator-option
*replicate*.node-uuid=52dca21b-c81c-48b5-9de2-1ed37987fbc2
===

Those are 5 to 6G, which is much less than dummy node has, but still
look too big for us.

Should we care about huge VIRT value on dummy node? Also, how one
would debug that?

Regards,
  Oleksandr.

[1] https://gist.github.com/d2cfa25251136512580220fcdb8a6ce6
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Huge VSZ (VIRT) usage by glustershd on dummy node

[Oleksandr Natalenko]

I believe, multi-threaded shd has not been merged at least into 3.7 
branch prior to 3.7.11 (incl.), because I've found this [1].


[1] https://www.gluster.org/pipermail/maintainers/2016-April/000628.html

06.06.2016 12:21, Kaushal M написав:

Has multi-threaded SHD been merged into 3.7.* by any chance? If not,
what I'm saying below doesn't apply.

We saw problems when encrypted transports were used, because the RPC
layer was not reaping threads (doing pthread_join) when a connection
ended. This lead to similar observations of huge VIRT and relatively
small RSS.

I'm not sure how multi-threaded shd works, but it could be leaking
threads in a similar way.

On Mon, Jun 6, 2016 at 1:54 PM, Oleksandr Natalenko
 wrote:

Hello.

We use v3.7.11, replica 2 setup between 2 nodes + 1 dummy node for 
keeping

volumes metadata.

Now we observe huge VSZ (VIRT) usage by glustershd on dummy node:

===
root 15109  0.0 13.7 76552820 535272 ? Ssl  тра26   2:11
/usr/sbin/glusterfs -s localhost --volfile-id gluster/glustershd -p
/var/lib/glusterd/glustershd/run/glustershd.pid -l
/var/log/glusterfs/glustershd.log -S
/var/run/gluster/7848e17764dd4ba80f4623aecb91b07a.socket 
--xlator-option

*replicate*.node-uuid=80bc95e1-2027-4a96-bb66-d9c8ade624d7
===

that is ~73G. RSS seems to be OK (~522M). Here is the statedump of
glustershd process: [1]

Also, here is sum of sizes, presented in statedump:

===
# cat /var/run/gluster/glusterdump.15109.dump.1465200139 | awk -F '=' 
'BEGIN

{sum=0} /^size=/ {sum+=$2} END {print sum}'
353276406
===

That is ~337 MiB.

Also, here are VIRT values from 2 replica nodes:

===
root 24659  0.0  0.3 5645836 451796 ?  Ssl  тра24   3:28
/usr/sbin/glusterfs -s localhost --volfile-id gluster/glustershd -p
/var/lib/glusterd/glustershd/run/glustershd.pid -l
/var/log/glusterfs/glustershd.log -S
/var/run/gluster/44ec3f29003eccedf894865107d5db90.socket 
--xlator-option

*replicate*.node-uuid=a19afcc2-e26c-43ce-bca6-d27dc1713e87
root 18312  0.0  0.3 6137500 477472 ?  Ssl  тра19   6:37
/usr/sbin/glusterfs -s localhost --volfile-id gluster/glustershd -p
/var/lib/glusterd/glustershd/run/glustershd.pid -l
/var/log/glusterfs/glustershd.log -S
/var/run/gluster/1670a3abbd1eea968126eb6f5be20322.socket 
--xlator-option

*replicate*.node-uuid=52dca21b-c81c-48b5-9de2-1ed37987fbc2
===

Those are 5 to 6G, which is much less than dummy node has, but still 
look

too big for us.

Should we care about huge VIRT value on dummy node? Also, how one 
would

debug that?

Regards,
  Oleksandr.

[1] https://gist.github.com/d2cfa25251136512580220fcdb8a6ce6
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Huge VSZ (VIRT) usage by glustershd on dummy node

[Kaushal M]

Has multi-threaded SHD been merged into 3.7.* by any chance? If not,
what I'm saying below doesn't apply.

We saw problems when encrypted transports were used, because the RPC
layer was not reaping threads (doing pthread_join) when a connection
ended. This lead to similar observations of huge VIRT and relatively
small RSS.

I'm not sure how multi-threaded shd works, but it could be leaking
threads in a similar way.

On Mon, Jun 6, 2016 at 1:54 PM, Oleksandr Natalenko
 wrote:
> Hello.
>
> We use v3.7.11, replica 2 setup between 2 nodes + 1 dummy node for keeping
> volumes metadata.
>
> Now we observe huge VSZ (VIRT) usage by glustershd on dummy node:
>
> ===
> root 15109  0.0 13.7 76552820 535272 ? Ssl  тра26   2:11
> /usr/sbin/glusterfs -s localhost --volfile-id gluster/glustershd -p
> /var/lib/glusterd/glustershd/run/glustershd.pid -l
> /var/log/glusterfs/glustershd.log -S
> /var/run/gluster/7848e17764dd4ba80f4623aecb91b07a.socket --xlator-option
> *replicate*.node-uuid=80bc95e1-2027-4a96-bb66-d9c8ade624d7
> ===
>
> that is ~73G. RSS seems to be OK (~522M). Here is the statedump of
> glustershd process: [1]
>
> Also, here is sum of sizes, presented in statedump:
>
> ===
> # cat /var/run/gluster/glusterdump.15109.dump.1465200139 | awk -F '=' 'BEGIN
> {sum=0} /^size=/ {sum+=$2} END {print sum}'
> 353276406
> ===
>
> That is ~337 MiB.
>
> Also, here are VIRT values from 2 replica nodes:
>
> ===
> root 24659  0.0  0.3 5645836 451796 ?  Ssl  тра24   3:28
> /usr/sbin/glusterfs -s localhost --volfile-id gluster/glustershd -p
> /var/lib/glusterd/glustershd/run/glustershd.pid -l
> /var/log/glusterfs/glustershd.log -S
> /var/run/gluster/44ec3f29003eccedf894865107d5db90.socket --xlator-option
> *replicate*.node-uuid=a19afcc2-e26c-43ce-bca6-d27dc1713e87
> root 18312  0.0  0.3 6137500 477472 ?  Ssl  тра19   6:37
> /usr/sbin/glusterfs -s localhost --volfile-id gluster/glustershd -p
> /var/lib/glusterd/glustershd/run/glustershd.pid -l
> /var/log/glusterfs/glustershd.log -S
> /var/run/gluster/1670a3abbd1eea968126eb6f5be20322.socket --xlator-option
> *replicate*.node-uuid=52dca21b-c81c-48b5-9de2-1ed37987fbc2
> ===
>
> Those are 5 to 6G, which is much less than dummy node has, but still look
> too big for us.
>
> Should we care about huge VIRT value on dummy node? Also, how one would
> debug that?
>
> Regards,
>   Oleksandr.
>
> [1] https://gist.github.com/d2cfa25251136512580220fcdb8a6ce6
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] dht mkdir preop check, afr and (non-)readable afr subvols

[Xavier Hernandez]

Hi Raghavendra,

On 06/06/16 10:54, Raghavendra G wrote:



On Wed, Jun 1, 2016 at 12:50 PM, Xavier Hernandez > wrote:

Hi,

On 01/06/16 08:53, Raghavendra Gowdappa wrote:



- Original Message -

From: "Xavier Hernandez" >
To: "Pranith Kumar Karampuri" >, "Raghavendra G"
>
Cc: "Gluster Devel" >
Sent: Wednesday, June 1, 2016 11:57:12 AM
Subject: Re: [Gluster-devel] dht mkdir preop check, afr and
(non-)readable afr subvols

Oops, you are right. For entry operations the current
version of the
parent directory is not checked, just to avoid this problem.

This means that mkdir will be sent to all alive subvolumes.
However it
still selects the group of answers that have a minimum
quorum equal or
greater than #bricks - redundancy. So it should be still valid.


What if the quorum is met on "bad" subvolumes? and mkdir was
successful on bad subvolumes? Do we consider mkdir as
successful? If yes, even EC suffers from the problem described
in bz https://bugzilla.redhat.com/show_bug.cgi?id=1341429.


I don't understand the real problem. How a subvolume of EC could be
in bad state from the point of view of DHT ?

If you use xattrs to configure something in the parent directories,
you should have needed to use setxattr or xattrop to do that. These
operations do consider good/bad bricks because they touch inode
metadata. This will only succeed if enough (quorum) bricks have
successfully processed it. If quorum is met but for an error answer,
an error will be reported to DHT and the majority of bricks will be
left in the old state (these should be considered the good
subvolumes). If some brick has succeeded, it will be considered bad
and will be healed. If no quorum is met (even for an error answer),
EIO will be returned and the state of the directory should be
considered unknown/damaged.


Yes. Ideally, dht should use a getxattr for the layout xattr. But, for
performance reasons we thought of overloading mkdir by introducing
pre-operations (done by bricks). With plain dht it is a simple
comparison of xattrs passed as argument and xattrs stored on disk. But,
I failed to include afr and EC in the picture.


I still miss something. Looking at the patch that implements this 
(http://review.gluster.org/13885), it seems that mkdir fails if the 
parent xattr is no correctly set, so it's not possible to create a 
directory on a "bad" brick.


If the majority of the subvolumes of ec fail, the whole request will 
fail and this failure will be reported to DHT. If the majority succeed, 
it will be reported to DHT, even is some of the subvolumes have failed.


Maybe if you give me a specific example I may see the real problem.

Xavi


Hence this issue. How
difficult for EC and AFR to bring this kind of check? Is it even
possible for afr and EC to implement this kind of pre-op checks with
reasonable complexity?


If a later mkdir checks this value in storage/posix and succeeds in
enough bricks, it necessarily means that is has succeeded in good
bricks, because there cannot be enough bricks with the bad xattr value.

Note that quorum is always > #bricks/2 so we cannot have a quorum
with good and bad bricks at the same time.

Xavi




Xavi

On 01/06/16 06:51, Pranith Kumar Karampuri wrote:

Xavi,
But if we keep winding only to good subvolumes,
there is a case
where bad subvolumes will never catch up right? i.e. if
we keep creating
files in same directory and everytime self-heal
completes there are more
entries mounts would have created on the good subvolumes
alone. I think
I must have missed this in the reviews if this is the
current behavior.
It was not in the earlier releases. Right?

Pranith

On Tue, May 31, 2016 at 2:17 PM, Raghavendra G

>> wrote:



On Tue, May 31, 2016 at 12:37 PM, Xavier Hernandez

>> 

Re: [Gluster-devel] dht mkdir preop check, afr and (non-)readable afr subvols

[Raghavendra G]

On Wed, Jun 1, 2016 at 12:50 PM, Xavier Hernandez 
wrote:

> Hi,
>
> On 01/06/16 08:53, Raghavendra Gowdappa wrote:
>
>>
>>
>> - Original Message -
>>
>>> From: "Xavier Hernandez" 
>>> To: "Pranith Kumar Karampuri" , "Raghavendra G" <
>>> raghaven...@gluster.com>
>>> Cc: "Gluster Devel" 
>>> Sent: Wednesday, June 1, 2016 11:57:12 AM
>>> Subject: Re: [Gluster-devel] dht mkdir preop check, afr and
>>> (non-)readable afr subvols
>>>
>>> Oops, you are right. For entry operations the current version of the
>>> parent directory is not checked, just to avoid this problem.
>>>
>>> This means that mkdir will be sent to all alive subvolumes. However it
>>> still selects the group of answers that have a minimum quorum equal or
>>> greater than #bricks - redundancy. So it should be still valid.
>>>
>>
>> What if the quorum is met on "bad" subvolumes? and mkdir was successful
>> on bad subvolumes? Do we consider mkdir as successful? If yes, even EC
>> suffers from the problem described in bz
>> https://bugzilla.redhat.com/show_bug.cgi?id=1341429.
>>
>
> I don't understand the real problem. How a subvolume of EC could be in bad
> state from the point of view of DHT ?
>
> If you use xattrs to configure something in the parent directories, you
> should have needed to use setxattr or xattrop to do that. These operations
> do consider good/bad bricks because they touch inode metadata. This will
> only succeed if enough (quorum) bricks have successfully processed it. If
> quorum is met but for an error answer, an error will be reported to DHT and
> the majority of bricks will be left in the old state (these should be
> considered the good subvolumes). If some brick has succeeded, it will be
> considered bad and will be healed. If no quorum is met (even for an error
> answer), EIO will be returned and the state of the directory should be
> considered unknown/damaged.
>

Yes. Ideally, dht should use a getxattr for the layout xattr. But, for
performance reasons we thought of overloading mkdir by introducing
pre-operations (done by bricks). With plain dht it is a simple comparison
of xattrs passed as argument and xattrs stored on disk. But, I failed to
include afr and EC in the picture. Hence this issue. How difficult for EC
and AFR to bring this kind of check? Is it even possible for afr and EC to
implement this kind of pre-op checks with reasonable complexity?


> If a later mkdir checks this value in storage/posix and succeeds in enough
> bricks, it necessarily means that is has succeeded in good bricks, because
> there cannot be enough bricks with the bad xattr value.
>
> Note that quorum is always > #bricks/2 so we cannot have a quorum with
> good and bad bricks at the same time.
>
> Xavi
>
>
>
>>
>>> Xavi
>>>
>>> On 01/06/16 06:51, Pranith Kumar Karampuri wrote:
>>>
 Xavi,
 But if we keep winding only to good subvolumes, there is a case
 where bad subvolumes will never catch up right? i.e. if we keep creating
 files in same directory and everytime self-heal completes there are more
 entries mounts would have created on the good subvolumes alone. I think
 I must have missed this in the reviews if this is the current behavior.
 It was not in the earlier releases. Right?

 Pranith

 On Tue, May 31, 2016 at 2:17 PM, Raghavendra G > wrote:



 On Tue, May 31, 2016 at 12:37 PM, Xavier Hernandez
 > wrote:

 Hi,

 On 31/05/16 07:05, Raghavendra Gowdappa wrote:

 +gluster-devel, +Xavi

 Hi all,

 The context is [1], where bricks do pre-operation checks
 before doing a fop and proceed with fop only if pre-op check
 is successful.

 @Xavi,

 We need your inputs on behavior of EC subvolumes as well.


 If I understand correctly, EC shouldn't have any problems here.

 EC sends the mkdir request to all subvolumes that are currently
 considered "good" and tries to combine the answers. Answers that
 match in return code, errno (if necessary) and xdata contents
 (except for some special xattrs that are ignored for combination
 purposes), are grouped.

 Then it takes the group with more members/answers. If that group
 has a minimum size of #bricks - redundancy, it is considered the
 good answer. Otherwise EIO is returned because bricks are in an
 inconsistent state.

 If there's any answer in another group, it's considered bad and
 gets marked so that self-heal will repair it using the good
 information from the 

Re: [Gluster-devel] one question in make install in 3.7.11

[Anoop C S]

On Tue, 2016-05-10 at 01:36 +, Liu, Li (Nokia - CN/Hangzhou) wrote:
> Hi
> 
> I follow this guideline to build gluster in 3.7.11
> http://gluster.readthedocs.io/en/latest/Developer-guide/Building-Glus
> terFS/
> 
> ./configure --enable-debug   --- works
> make-- works
> make install  -- some errors
> 
> 
> 
> GlusterFS configure summary
> ===
> FUSE client  : yes
> Infiniband verbs : yes
> epoll IO multiplex   : yes
> argp-standalone  : no
> fusermount   : yes
> readline : yes
> georeplication   : yes
> Linux-AIO: yes
> Enable Debug : yes
> Block Device xlator  : yes
> glupy: yes
> Use syslog   : yes
> XML output   : yes
> QEMU Block formats   : yes
> Encryption xlator: yes
> Unit Tests   : no
> POSIX ACLs   : yes
> Data Classification  : yes
> firewalld-config : no
> 
> 
> 
> Making install in glupy
> Making install in src
> Making install in glupy
>  /usr/bin/mkdir -p '/usr/lib/python2.7/site-packages/gluster/glupy'
>  /usr/bin/install -c -m 644 __init__.py '/usr/lib/python2.7/site-
> packages/gluster/glupy'
> ../../../../../py-compile: Missing argument to --destdir.
> make[6]: *** [install-pyglupyPYTHON] Error 1
> make[5]: *** [install-am] Error 2
> make[4]: *** [install-recursive] Error 1
> make[3]: *** [install-recursive] Error 1
> make[2]: *** [install-recursive] Error 1
> make[1]: *** [install-recursive] Error 1
> make: *** [install-recursive] Error 1
> 
> do you know where is my faults?
> 

Assuming that you are compiling from the release tar ball downloaded
from download.gluster.org, this error happens due to the difference in
automake versions used to prepare the tar ball and the one used during
make install. There are two ways to get around this issue:

[1] If the automake version version installed on your machine is >=
1.11.2, then remove the file named 'py-compile' from root of the
release tar ball source and start again from running ./autogen.sh and
continue.

[2] If your automake version is < 1.11.2, then run make install as
follows
# make install DESTDIR=/

If you are facing this error from source which is a git clone, then
probably you may need to either upgrade automake to some version >=
1.11.2 and follow the 1st workaround or run make install by explicitly
setting DESTDIR to / as mentioned in the 2nd workaround above.

--Anoop C S.

> Or you can tell me where I can rise one question
> 
> Thank you very much!
> 
> Liuli
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Huge VSZ (VIRT) usage by glustershd on dummy node

[Oleksandr Natalenko]

Hello.

We use v3.7.11, replica 2 setup between 2 nodes + 1 dummy node for 
keeping volumes metadata.


Now we observe huge VSZ (VIRT) usage by glustershd on dummy node:

===
root 15109  0.0 13.7 76552820 535272 ? Ssl  тра26   2:11 
/usr/sbin/glusterfs -s localhost --volfile-id gluster/glustershd -p 
/var/lib/glusterd/glustershd/run/glustershd.pid -l 
/var/log/glusterfs/glustershd.log -S 
/var/run/gluster/7848e17764dd4ba80f4623aecb91b07a.socket --xlator-option 
*replicate*.node-uuid=80bc95e1-2027-4a96-bb66-d9c8ade624d7

===

that is ~73G. RSS seems to be OK (~522M). Here is the statedump of 
glustershd process: [1]


Also, here is sum of sizes, presented in statedump:

===
# cat /var/run/gluster/glusterdump.15109.dump.1465200139 | awk -F '=' 
'BEGIN {sum=0} /^size=/ {sum+=$2} END {print sum}'

353276406
===

That is ~337 MiB.

Also, here are VIRT values from 2 replica nodes:

===
root 24659  0.0  0.3 5645836 451796 ?  Ssl  тра24   3:28 
/usr/sbin/glusterfs -s localhost --volfile-id gluster/glustershd -p 
/var/lib/glusterd/glustershd/run/glustershd.pid -l 
/var/log/glusterfs/glustershd.log -S 
/var/run/gluster/44ec3f29003eccedf894865107d5db90.socket --xlator-option 
*replicate*.node-uuid=a19afcc2-e26c-43ce-bca6-d27dc1713e87
root 18312  0.0  0.3 6137500 477472 ?  Ssl  тра19   6:37 
/usr/sbin/glusterfs -s localhost --volfile-id gluster/glustershd -p 
/var/lib/glusterd/glustershd/run/glustershd.pid -l 
/var/log/glusterfs/glustershd.log -S 
/var/run/gluster/1670a3abbd1eea968126eb6f5be20322.socket --xlator-option 
*replicate*.node-uuid=52dca21b-c81c-48b5-9de2-1ed37987fbc2

===

Those are 5 to 6G, which is much less than dummy node has, but still 
look too big for us.


Should we care about huge VIRT value on dummy node? Also, how one would 
debug that?


Regards,
  Oleksandr.

[1] https://gist.github.com/d2cfa25251136512580220fcdb8a6ce6
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Error in release-3.8

[Niels de Vos]

On Mon, Jun 06, 2016 at 11:33:04AM +0530, Saravanakumar Arumugam wrote:
> Hi,
> 
> Observed error in release-3.8.
> 
> It seems like some environment setup issue :
> 
> 22:52:45 
> /home/jenkins/root/workspace/rackspace-regression-2GB-triggered/rpc/rpc-lib/src/rpc-clnt.c:1877:
> fatal error: opening dependency file .deps/rpc-clnt.Tpo: No such file or
> directory
> 22:52:45 compilation terminated.
> 22:52:45 
> /home/jenkins/root/workspace/rackspace-regression-2GB-triggered/rpc/rpc-lib/src/rpc-drc.c:856:
> fatal error: opening dependency file .deps/rpc-drc.Tpo: No such file or
> directory
> 22:52:45 compilation terminated.
> 22:52:46 
> /home/jenkins/root/workspace/rackspace-regression-2GB-triggered/rpc/rpc-lib/src/rpc-clnt-ping.c:338:
> fatal error: opening dependency file .deps/rpc-clnt-ping.Tpo: No such file
> or directory
> 22:52:46 compilation terminated.
> 22:52:46 make[3]: *** [rpc-drc.lo] Error 1
> 22:52:46 make[3]: *** Waiting for unfinished jobs
> 22:52:46 The bug is not reproducible, so it is likely a hardware or OS
> problem.
> 
> Logs here:
> https://build.gluster.org/job/rackspace-regression-2GB-triggered/21420/consoleFull

Both this error and the other one you reported for release-3.7 were
running on slave23.cloud.gluster.org. Currently tests are succeeding on
this system, so maybe someone fixed it already?

  https://build.gluster.org/computer/slave23.cloud.gluster.org/builds

Niels


signature.asc
Description: PGP signature
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Patch Review

[Ashish Pandey]

Hi All, 

I have modified the code for volume file generation to support decompounder 
translator. 
Please review this patch and provide me your comments/suggestion. 
http://review.gluster.org/#/c/13968/ 

Ashish 
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Error in release-3.8

[Saravanakumar Arumugam]

Hi,

Observed error in release-3.8.

It seems like some environment setup issue :

22:52:45 
/home/jenkins/root/workspace/rackspace-regression-2GB-triggered/rpc/rpc-lib/src/rpc-clnt.c:1877: 
fatal error: opening dependency file .deps/rpc-clnt.Tpo: No such file or 
directory

22:52:45 compilation terminated.
22:52:45 
/home/jenkins/root/workspace/rackspace-regression-2GB-triggered/rpc/rpc-lib/src/rpc-drc.c:856: 
fatal error: opening dependency file .deps/rpc-drc.Tpo: No such file or 
directory

22:52:45 compilation terminated.
22:52:46 
/home/jenkins/root/workspace/rackspace-regression-2GB-triggered/rpc/rpc-lib/src/rpc-clnt-ping.c:338: 
fatal error: opening dependency file .deps/rpc-clnt-ping.Tpo: No such 
file or directory

22:52:46 compilation terminated.
22:52:46 make[3]: *** [rpc-drc.lo] Error 1
22:52:46 make[3]: *** Waiting for unfinished jobs
22:52:46 The bug is not reproducible, so it is likely a hardware or OS 
problem.


Logs here:
https://build.gluster.org/job/rackspace-regression-2GB-triggered/21420/consoleFull


Thanks,
Saravana

___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel