date:20180121

Re: [Gluster-users] [Gluster-devel] configure fails due to failure in locating libxml2-devel

2018-01-21 Thread Raghavendra G

On Mon, Jan 22, 2018 at 11:32 AM, Kaushal M  wrote:

> Did you run autogen.sh after installing libxml2-devel?
>

I hadn't. I did it now and configure succeeds. Thanks Kaushal.


> On Mon, Jan 22, 2018 at 11:10 AM, Raghavendra G
>  wrote:
> > All,
> >
> > # ./configure
> > 
> > configure: error: libxml2 devel libraries not found
> >
> > # ls /usr/lib64/libxml2.so
> > /usr/lib64/libxml2.so
> >
> > # ls /usr/include/libxml2/
> > libxml
> >
> > # yum install libxml2-devel
> > Package libxml2-devel-2.9.1-6.el7_2.3.x86_64 already installed and
> latest
> > version
> > Nothing to do
> >
> > Looks like the issue is very similar to one filed in:
> > https://bugzilla.redhat.com/show_bug.cgi?id=64134
> >
> > Has anyone encountered this? How did you workaround this?
> >
> > regards,
> > --
> > Raghavendra G
> >
> >
> > ___
> > Gluster-devel mailing list
> > gluster-de...@gluster.org
> > http://lists.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Raghavendra G
___
Gluster-users mailing list
Gluster-users@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-users

Re: [Gluster-users] [Gluster-devel] Integration of GPU with glusterfs

2018-01-21 Thread Ashish Pandey


Based on my understanding of GPU and CUDA programming, I think we should write 
some API"s which 
different translators can use. I just explored EC code where we are doing 
computation to encode and decode user data 
and found that it could be a better idea to provide API's. 

--- 
Ashish 


- Original Message -

From: "Vijay Bellur"  
To: "Ashish Pandey"  
Cc: "gluster-users" , "Gluster Devel" 
 
Sent: Monday, January 15, 2018 10:29:42 PM 
Subject: Re: [Gluster-users] [Gluster-devel] Integration of GPU with glusterfs 



On Mon, Jan 15, 2018 at 12:06 AM, Ashish Pandey < aspan...@redhat.com > wrote: 




It is disappointing to see the limitation being put by Nvidia on low cost GPU 
usage on data centers. 
https://www.theregister.co.uk/2018/01/03/nvidia_server_gpus/ 

We thought of providing an option in glusterfs by which we can control if we 
want to use GPU or not. 
So, the concern of gluster eating out GPU's which could be used by others can 
be addressed. 





It would be definitely be interesting to try this out. This limitation may 
change in the future and the higher end GPUs are still usable in data centers. 

Do you have more details on the proposed implementation? 

Thanks, 
Vijay 






--- 
Ashish 




From: "Jim Kinney" < jim.kin...@gmail.com > 
To: gluster-users@gluster.org , "Lindsay Mathieson" < 
lindsay.mathie...@gmail.com >, "Darrell Budic" < bu...@onholyground.com >, 
"Gluster Users" < gluster-users@gluster.org > 
Cc: "Gluster Devel" < gluster-de...@gluster.org > 
Sent: Friday, January 12, 2018 6:00:25 PM 
Subject: Re: [Gluster-devel] [Gluster-users] Integration of GPU with glusterfs 



On January 11, 2018 10:58:28 PM EST, Lindsay Mathieson < 
lindsay.mathie...@gmail.com > wrote: 
>On 12/01/2018 3:14 AM, Darrell Budic wrote: 
>> It would also add physical resource requirements to future client 
>> deploys, requiring more than 1U for the server (most likely), and I’m 
> 
>> not likely to want to do this if I’m trying to optimize for client 
>> density, especially with the cost of GPUs today. 
> 
>Nvidia has banned their GPU's being used in Data Centers now to, I 
>imagine they are planning to add a licensing fee. 

Nvidia banned only the lower cost, home user versions of their GPU line from 
datacenters. 
> 
>-- 
>Lindsay Mathieson 
> 
>___ 
>Gluster-users mailing list 
> Gluster-users@gluster.org 
> http://lists.gluster.org/mailman/listinfo/gluster-users 

-- 
Sent from my Android device with K-9 Mail. All tyopes are thumb related and 
reflect authenticity. 
___ 
Gluster-devel mailing list 
gluster-de...@gluster.org 
http://lists.gluster.org/mailman/listinfo/gluster-devel 


___ 
Gluster-users mailing list 
Gluster-users@gluster.org 
http://lists.gluster.org/mailman/listinfo/gluster-users 





___ 
Gluster-users mailing list 
Gluster-users@gluster.org 
http://lists.gluster.org/mailman/listinfo/gluster-users 

___
Gluster-users mailing list
Gluster-users@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-users

Re: [Gluster-users] [Gluster-devel] configure fails due to failure in locating libxml2-devel

2018-01-21 Thread Kaushal M

Did you run autogen.sh after installing libxml2-devel?

On Mon, Jan 22, 2018 at 11:10 AM, Raghavendra G
 wrote:
> All,
>
> # ./configure
> 
> configure: error: libxml2 devel libraries not found
>
> # ls /usr/lib64/libxml2.so
> /usr/lib64/libxml2.so
>
> # ls /usr/include/libxml2/
> libxml
>
> # yum install libxml2-devel
> Package libxml2-devel-2.9.1-6.el7_2.3.x86_64 already installed and latest
> version
> Nothing to do
>
> Looks like the issue is very similar to one filed in:
> https://bugzilla.redhat.com/show_bug.cgi?id=64134
>
> Has anyone encountered this? How did you workaround this?
>
> regards,
> --
> Raghavendra G
>
>
> ___
> Gluster-devel mailing list
> gluster-de...@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
___
Gluster-users mailing list
Gluster-users@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-users

Re: [Gluster-users] [Gluster-devel] cluster/dht: restrict migration of opened files

2018-01-21 Thread Raghavendra G

On Thu, Jan 18, 2018 at 8:11 PM, Pranith Kumar Karampuri <
pkara...@redhat.com> wrote:

>
>
> On Tue, Jan 16, 2018 at 2:52 PM, Raghavendra Gowdappa  > wrote:
>
>> All,
>>
>> Patch [1] prevents migration of opened files during rebalance operation.
>> If patch [1] affects you, please voice out your concerns. [1] is a stop-gap
>> fix for the problem discussed in issues [2][3]
>>
>
> What is the impact on VM and gluster-block usecases after this patch? Will
> it rebalance any data in these usecases?
>

Assuming there is an fd opened on these files always and if
cluster.force-migration is set to off, there will be no migration. However,
we can force migration (even on files with open fds) by setting
cluster.force-migration to on.


>
>>
>> [1] https://review.gluster.org/#/c/19202/
>> [2] https://github.com/gluster/glusterfs/issues/308
>> [3] https://github.com/gluster/glusterfs/issues/347
>>
>> regards,
>> Raghavendra
>>
>> ___
>> Gluster-devel mailing list
>> gluster-de...@gluster.org
>> http://lists.gluster.org/mailman/listinfo/gluster-devel
>>
>
>
>
> --
> Pranith
>
> ___
> Gluster-devel mailing list
> gluster-de...@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Raghavendra G
___
Gluster-users mailing list
Gluster-users@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-users

[Gluster-users] configure fails due to failure in locating libxml2-devel

2018-01-21 Thread Raghavendra G

All,

# ./configure

configure: error: libxml2 devel libraries not found

# ls /usr/lib64/libxml2.so
/usr/lib64/libxml2.so

# ls /usr/include/libxml2/
libxml

# yum install libxml2-devel
Package libxml2-devel-2.9.1-6.el7_2.3.x86_64 already installed and latest
version
Nothing to do

Looks like the issue is very similar to one filed in:
https://bugzilla.redhat.com/show_bug.cgi?id=64134

Has anyone encountered this? How did you workaround this?

regards,
-- 
Raghavendra G
___
Gluster-users mailing list
Gluster-users@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-users

Re: [Gluster-users] BUG: After stop and start wrong port is advertised

2018-01-21 Thread Atin Mukherjee

The patch was definitely there in 3.12.3. Do you have the glusterd and
brick logs handy with you when this happened?

On Sun, Jan 21, 2018 at 10:21 PM, Alan Orth  wrote:

> For what it's worth, I just updated some CentOS 7 servers from GlusterFS
> 3.12.1 to 3.12.4 and hit this bug. Did the patch make it into 3.12.4? I had
> to use Mike Hulsman's script to check the daemon port against the port in
> the volume's brick info, update the port, and restart glusterd on each
> node. Luckily I only have four servers! Hoping I don't have to do this
> every time I reboot!
>
> Regards,
>
> On Sat, Dec 2, 2017 at 5:23 PM Atin Mukherjee  wrote:
>
>> On Sat, 2 Dec 2017 at 19:29, Jo Goossens 
>> wrote:
>>
>>> Hello Atin,
>>>
>>>
>>>
>>>
>>>
>>> Could you confirm this should have been fixed in 3.10.8? If so we'll
>>> test it for sure!
>>>
>>
>> Fix should be part of 3.10.8 which is awaiting release announcement.
>>
>>
>>>
>>> Regards
>>>
>>> Jo
>>>
>>>
>>>
>>>
>>>
>>>
>>> -Original message-
>>> *From:* Atin Mukherjee 
>>>
>>> *Sent:* Mon 30-10-2017 17:40
>>> *Subject:* Re: [Gluster-users] BUG: After stop and start wrong port is
>>> advertised
>>> *To:* Jo Goossens ;
>>> *CC:* gluster-users@gluster.org;
>>>
>>> On Sat, 28 Oct 2017 at 02:36, Jo Goossens 
>>> wrote:
>>>
>>> Hello Atin,
>>>
>>>
>>>
>>>
>>>
>>> I just read it and very happy you found the issue. We really hope this
>>> will be fixed in the next 3.10.7 version!
>>>
>>>
>>> 3.10.7 - no I guess as the patch is still in review and 3.10.7 is
>>> getting tagged today. You’ll get this fix in 3.10.8.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> PS: Wow nice all that c code and those "goto out" statements (not always
>>> considered clean but the best way often I think). Can remember the days I
>>> wrote kernel drivers myself in c :)
>>>
>>>
>>>
>>>
>>>
>>> Regards
>>>
>>> Jo Goossens
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> -Original message-
>>> *From:* Atin Mukherjee 
>>> *Sent:* Fri 27-10-2017 21:01
>>> *Subject:* Re: [Gluster-users] BUG: After stop and start wrong port is
>>> advertised
>>> *To:* Jo Goossens ;
>>> *CC:* gluster-users@gluster.org;
>>>
>>> We (finally) figured out the root cause, Jo!
>>>
>>> Patch https://review.gluster.org/#/c/18579 posted upstream for review.
>>>
>>> On Thu, Sep 21, 2017 at 2:08 PM, Jo Goossens <
>>> jo.gooss...@hosted-power.com> wrote:
>>>
>>> Hi,
>>>
>>>
>>>
>>>
>>>
>>> We use glusterfs 3.10.5 on Debian 9.
>>>
>>>
>>>
>>> When we stop or restart the service, e.g.: service glusterfs-server
>>> restart
>>>
>>>
>>>
>>> We see that the wrong port get's advertised afterwards. For example:
>>>
>>>
>>>
>>> Before restart:
>>>
>>>
>>> Status of volume: public
>>> Gluster process TCP Port  RDMA Port  Online
>>>  Pid
>>> 
>>> --
>>> Brick 192.168.140.41:/gluster/public49153 0  Y
>>>   6364
>>> Brick 192.168.140.42:/gluster/public49152 0  Y
>>>   1483
>>> Brick 192.168.140.43:/gluster/public49152 0  Y
>>>   5913
>>> Self-heal Daemon on localhost   N/A   N/AY
>>> 5932
>>> Self-heal Daemon on 192.168.140.42  N/A   N/AY
>>> 13084
>>> Self-heal Daemon on 192.168.140.41  N/A   N/AY
>>> 15499
>>>
>>> Task Status of Volume public
>>> 
>>> --
>>> There are no active volume tasks
>>>
>>>
>>> After restart of the service on one of the nodes (192.168.140.43) the
>>> port seems to have changed (but it didn't):
>>>
>>> root@app3:/var/log/glusterfs#  gluster volume status
>>> Status of volume: public
>>> Gluster process TCP Port  RDMA Port  Online
>>>  Pid
>>> 
>>> --
>>> Brick 192.168.140.41:/gluster/public49153 0  Y
>>>   6364
>>> Brick 192.168.140.42:/gluster/public49152 0  Y
>>>   1483
>>> Brick 192.168.140.43:/gluster/public49154 0  Y
>>>   5913
>>> Self-heal Daemon on localhost   N/A   N/AY
>>> 4628
>>> Self-heal Daemon on 192.168.140.42  N/A   N/AY
>>> 3077
>>> Self-heal Daemon on 192.168.140.41  N/A   N/AY
>>> 28777
>>>
>>> Task Status of Volume public
>>> 
>>> --
>>> There are no active volume tasks
>>>
>>>
>>> However the active process is STILL the same pid AND still listening on
>>> the old port
>>>
>>> root@192.168.140.43:/var/log/glusterfs# netstat -tapn | grep gluster
>>> tcp0  0 0.0.0.0:49152   0.0.0.0:*
>>> LISTEN

Re: [Gluster-users] Stale locks on shards

2018-01-21 Thread Samuli Heinonen


Hi again,

here is more information regarding issue described earlier

It looks like self healing is stuck. According to "heal statistics" 
crawl began at Sat Jan 20 12:56:19 2018 and it's still going on (It's 
around Sun Jan 21 20:30 when writing this). However glustershd.log says 
that last heal was completed at "2018-01-20 11:00:13.090697" (which is 
13:00 UTC+2). Also "heal info" has been running now for over 16 hours 
without any information. In statedump I can see that storage nodes have 
locks on files and some of those are blocked. Ie. Here again it says 
that ovirt8z2 is having active lock even ovirt8z2 crashed after the lock 
was granted.:


[xlator.features.locks.zone2-ssd1-vmstor1-locks.inode]
path=/.shard/3d55f8cc-cda9-489a-b0a3-fd0f43d67876.27
mandatory=0
inodelk-count=3
lock-dump.domain.domain=zone2-ssd1-vmstor1-replicate-0:self-heal
inodelk.inodelk[0](ACTIVE)=type=WRITE, whence=0, start=0, len=0, pid = 
18446744073709551610, owner=d0c6d857a87f, client=0x7f885845efa0, 
connection-id=sto2z2.xxx-10975-2018/01/20-10:56:14:649541-zone2-ssd1-vmstor1-client-0-0-0, 
granted at 2018-01-20 10:59:52

lock-dump.domain.domain=zone2-ssd1-vmstor1-replicate-0:metadata
lock-dump.domain.domain=zone2-ssd1-vmstor1-replicate-0
inodelk.inodelk[0](ACTIVE)=type=WRITE, whence=0, start=0, len=0, pid = 
3420, owner=d8b9372c397f, client=0x7f8858410be0, 
connection-id=ovirt8z2.xxx.com-5652-2017/12/27-09:49:02:946825-zone2-ssd1-vmstor1-client-0-7-0, 
granted at 2018-01-20 08:57:23
inodelk.inodelk[1](BLOCKED)=type=WRITE, whence=0, start=0, len=0, pid = 
18446744073709551610, owner=d0c6d857a87f, client=0x7f885845efa0, 
connection-id=sto2z2.xxx-10975-2018/01/20-10:56:14:649541-zone2-ssd1-vmstor1-client-0-0-0, 
blocked at 2018-01-20 10:59:52


I'd also like to add that volume had arbiter brick before crash 
happened. We decided to remove it because we thought that it was causing 
issues. However now I think that this was unnecessary. After the crash 
arbiter logs had lots of messages like this:
[2018-01-20 10:19:36.515717] I [MSGID: 115072] 
[server-rpc-fops.c:1640:server_setattr_cbk] 0-zone2-ssd1-vmstor1-server: 
37374187: SETATTR  
(a52055bd-e2e9-42dd-92a3-e96b693bcafe) ==> (Operation not permitted) 
[Operation not permitted]


Is there anyways to force self heal to stop? Any help would be very much 
appreciated :)


Best regards,
Samuli Heinonen






Samuli Heinonen 
20 January 2018 at 21.57
Hi all!

One hypervisor on our virtualization environment crashed and now some 
of the VM images cannot be accessed. After investigation we found out 
that there was lots of images that still had active lock on crashed 
hypervisor. We were able to remove locks from "regular files", but it 
doesn't seem possible to remove locks from shards.


We are running GlusterFS 3.8.15 on all nodes.

Here is part of statedump that shows shard having active lock on 
crashed node:

[xlator.features.locks.zone2-ssd1-vmstor1-locks.inode]
path=/.shard/75353c17-d6b8-485d-9baf-fd6c700e39a1.21
mandatory=0
inodelk-count=1
lock-dump.domain.domain=zone2-ssd1-vmstor1-replicate-0:metadata
lock-dump.domain.domain=zone2-ssd1-vmstor1-replicate-0:self-heal
lock-dump.domain.domain=zone2-ssd1-vmstor1-replicate-0
inodelk.inodelk[0](ACTIVE)=type=WRITE, whence=0, start=0, len=0, pid = 
3568, owner=14ce372c397f, client=0x7f3198388770, connection-id 
ovirt8z2.xxx-5652-2017/12/27-09:49:02:946825-zone2-ssd1-vmstor1-client-1-7-0, 
granted at 2018-01-20 08:57:24


If we try to run clear-locks we get following error message:
# gluster volume clear-locks zone2-ssd1-vmstor1 
/.shard/75353c17-d6b8-485d-9baf-fd6c700e39a1.21 kind all inode

Volume clear-locks unsuccessful
clear-locks getxattr command failed. Reason: Operation not permitted

Gluster vol info if needed:
Volume Name: zone2-ssd1-vmstor1
Type: Replicate
Volume ID: b6319968-690b-4060-8fff-b212d2295208
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x 2 = 2
Transport-type: rdma
Bricks:
Brick1: sto1z2.xxx:/ssd1/zone2-vmstor1/export
Brick2: sto2z2.xxx:/ssd1/zone2-vmstor1/export
Options Reconfigured:
cluster.shd-wait-qlength: 1
cluster.shd-max-threads: 8
cluster.locking-scheme: granular
performance.low-prio-threads: 32
cluster.data-self-heal-algorithm: full
performance.client-io-threads: off
storage.linux-aio: off
performance.readdir-ahead: on
client.event-threads: 16
server.event-threads: 16
performance.strict-write-ordering: off
performance.quick-read: off
performance.read-ahead: on
performance.io-cache: off
performance.stat-prefetch: off
cluster.eager-lock: enable
network.remote-dio: on
cluster.quorum-type: none
network.ping-timeout: 22
performance.write-behind: off
nfs.disable: on
features.shard: on
features.shard-block-size: 512MB
storage.owner-uid: 36
storage.owner-gid: 36
performance.io-thread-count: 64
performance.cache-size: 2048MB
performance.write-behind-window-size: 256MB
server.allow-insecure: on
cluster.ensure-durability: off
config.transport: rdma

Re: [Gluster-users] BUG: After stop and start wrong port is advertised

2018-01-21 Thread Alan Orth

For what it's worth, I just updated some CentOS 7 servers from GlusterFS
3.12.1 to 3.12.4 and hit this bug. Did the patch make it into 3.12.4? I had
to use Mike Hulsman's script to check the daemon port against the port in
the volume's brick info, update the port, and restart glusterd on each
node. Luckily I only have four servers! Hoping I don't have to do this
every time I reboot!

Regards,

On Sat, Dec 2, 2017 at 5:23 PM Atin Mukherjee  wrote:

> On Sat, 2 Dec 2017 at 19:29, Jo Goossens 
> wrote:
>
>> Hello Atin,
>>
>>
>>
>>
>>
>> Could you confirm this should have been fixed in 3.10.8? If so we'll test
>> it for sure!
>>
>
> Fix should be part of 3.10.8 which is awaiting release announcement.
>
>
>>
>> Regards
>>
>> Jo
>>
>>
>>
>>
>>
>>
>> -Original message-
>> *From:* Atin Mukherjee 
>>
>> *Sent:* Mon 30-10-2017 17:40
>> *Subject:* Re: [Gluster-users] BUG: After stop and start wrong port is
>> advertised
>> *To:* Jo Goossens ;
>> *CC:* gluster-users@gluster.org;
>>
>> On Sat, 28 Oct 2017 at 02:36, Jo Goossens 
>> wrote:
>>
>> Hello Atin,
>>
>>
>>
>>
>>
>> I just read it and very happy you found the issue. We really hope this
>> will be fixed in the next 3.10.7 version!
>>
>>
>> 3.10.7 - no I guess as the patch is still in review and 3.10.7 is getting
>> tagged today. You’ll get this fix in 3.10.8.
>>
>>
>>
>>
>>
>>
>>
>>
>> PS: Wow nice all that c code and those "goto out" statements (not always
>> considered clean but the best way often I think). Can remember the days I
>> wrote kernel drivers myself in c :)
>>
>>
>>
>>
>>
>> Regards
>>
>> Jo Goossens
>>
>>
>>
>>
>>
>>
>>
>>
>> -Original message-
>> *From:* Atin Mukherjee 
>> *Sent:* Fri 27-10-2017 21:01
>> *Subject:* Re: [Gluster-users] BUG: After stop and start wrong port is
>> advertised
>> *To:* Jo Goossens ;
>> *CC:* gluster-users@gluster.org;
>>
>> We (finally) figured out the root cause, Jo!
>>
>> Patch https://review.gluster.org/#/c/18579 posted upstream for review.
>>
>> On Thu, Sep 21, 2017 at 2:08 PM, Jo Goossens <
>> jo.gooss...@hosted-power.com> wrote:
>>
>> Hi,
>>
>>
>>
>>
>>
>> We use glusterfs 3.10.5 on Debian 9.
>>
>>
>>
>> When we stop or restart the service, e.g.: service glusterfs-server
>> restart
>>
>>
>>
>> We see that the wrong port get's advertised afterwards. For example:
>>
>>
>>
>> Before restart:
>>
>>
>> Status of volume: public
>> Gluster process TCP Port  RDMA Port  Online
>>  Pid
>>
>> --
>> Brick 192.168.140.41:/gluster/public49153 0  Y
>> 6364
>> Brick 192.168.140.42:/gluster/public49152 0  Y
>> 1483
>> Brick 192.168.140.43:/gluster/public49152 0  Y
>> 5913
>> Self-heal Daemon on localhost   N/A   N/AY
>> 5932
>> Self-heal Daemon on 192.168.140.42  N/A   N/AY
>> 13084
>> Self-heal Daemon on 192.168.140.41  N/A   N/AY
>> 15499
>>
>> Task Status of Volume public
>>
>> --
>> There are no active volume tasks
>>
>>
>> After restart of the service on one of the nodes (192.168.140.43) the
>> port seems to have changed (but it didn't):
>>
>> root@app3:/var/log/glusterfs#  gluster volume status
>> Status of volume: public
>> Gluster process TCP Port  RDMA Port  Online
>>  Pid
>>
>> --
>> Brick 192.168.140.41:/gluster/public49153 0  Y
>> 6364
>> Brick 192.168.140.42:/gluster/public49152 0  Y
>> 1483
>> Brick 192.168.140.43:/gluster/public49154 0  Y
>> 5913
>> Self-heal Daemon on localhost   N/A   N/AY
>> 4628
>> Self-heal Daemon on 192.168.140.42  N/A   N/AY
>> 3077
>> Self-heal Daemon on 192.168.140.41  N/A   N/AY
>> 28777
>>
>> Task Status of Volume public
>>
>> --
>> There are no active volume tasks
>>
>>
>> However the active process is STILL the same pid AND still listening on
>> the old port
>>
>> root@192.168.140.43:/var/log/glusterfs# netstat -tapn | grep gluster
>> tcp0  0 0.0.0.0:49152   0.0.0.0:*
>> LISTEN  5913/glusterfsd
>>
>>
>> The other nodes logs fill up with errors because they can't reach the
>> daemon anymore. They try to reach it on the "new" port instead of the old
>> one:
>>
>> [2017-09-21 08:33:25.225006] E [socket.c:2327:socket_connect_finish]
>> 0-public-client-2: connection to 192.168.140.43:49154 failed (Connection
>> refused); disconnecting socket
>> [2017-09-21 08:33:29.226633] I

[Gluster-users] mkdir -p, cp -R fails

2018-01-21 Thread Stefan Solbrig

Dear all,

I have problem with glusterfs 3.12.4  

mkdir -p  fails with "no data available" when umask is 0022, but works when 
umask is 0002. 

Also recursive copy  (cp -R  or cp -r) fails with "no data available", 
independly of the umask.

See below for an example to reproduce the error.  I already tried to change 
transport from rdma to tcp. (Changing the transport works, but the error 
persists.)

I'd be grateful for some insight.

I have small test system that still runs on glusterfs 3.12.3, where everything 
works fine.

best wishes,
Stefan



[hpcadmin@pcph00131 bug]$ mount | grep gluster 
qloginx:/glurch.rdma on /glurch type fuse.glusterfs 
(rw,relatime,user_id=0,group_id=0,allow_other,max_read=131072)


[hpcadmin@pcph00131 bug]$ pwd
/glurch/test/bug

[hpcadmin@pcph00131 bug]$ umask 0022 
[hpcadmin@pcph00131 bug]$ mkdir aa #works
[hpcadmin@pcph00131 bug]$ mkdir -p aa/bb/cc/dd 
mkdir: cannot create directory ‘aa/bb’: No data available


[hpcadmin@pcph00131 bug]$ umask 0002 
[hpcadmin@pcph00131 bug]$ mkdir -p aa/bb/cc/dd 
mkdir: cannot create directory ‘aa/bb’: No data available

[hpcadmin@pcph00131 bug]$ rm -rf aa 
[hpcadmin@pcph00131 bug]$ mkdir -p aa/bb/cc/dd #works now
# looks like all directories in the path of mkdir -p ...
# have to be group-writable... 

[hpcadmin@pcph00131 bug]$ cp -R aa foo 
cp: cannot create directory ‘foo/bb’: No data available
# I cannot get this to work, independ of the umask...

[hpcadmin@pcph00131 bug]$ glusterd --version 
glusterfs 3.12.4

[hpcadmin@pcph00131 bug]$ glusterfs  --version
glusterfs 3.12.4

[hpcadmin@pcph00131 bug]$ glusterfsd --version
glusterfs 3.12.4

[hpcadmin@pcph00131 bug]$ sudo gluster v status all 
Status of volume: glurch
Gluster process TCP Port  RDMA Port  Online  Pid
--
Brick qloginx:/gl/lv1osb06/glurchbrick  0 49152  Y   17623
Brick qloginx:/gl/lv2osb06/glurchbrick  0 49153  Y   17647
Brick gluster2x:/gl/lv3osb06/glurchbrick0 49152  Y   2845 
Brick gluster2x:/gl/lv4osb06/glurchbrick0 49153  Y   2868 

#note: im mounting on the qlogin



-- 
Dr. Stefan Solbrig
Universität Regensburg, Fakultät für Physik,
93040 Regensburg, Germany
Tel +49-941-943-2097


___
Gluster-users mailing list
Gluster-users@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-users

Re: [Gluster-users] [Gluster-devel] configure fails due to failure in locating libxml2-devel

Re: [Gluster-users] [Gluster-devel] Integration of GPU with glusterfs

Re: [Gluster-users] [Gluster-devel] configure fails due to failure in locating libxml2-devel

Re: [Gluster-users] [Gluster-devel] cluster/dht: restrict migration of opened files

[Gluster-users] configure fails due to failure in locating libxml2-devel

Re: [Gluster-users] BUG: After stop and start wrong port is advertised

Re: [Gluster-users] Stale locks on shards

Re: [Gluster-users] BUG: After stop and start wrong port is advertised

[Gluster-users] mkdir -p, cp -R fails

9 matches

Site Navigation

Mail list logo

Footer information