date:20170718

Re: [Gluster-users] moving drives containing bricks from one server to another

2017-07-18 Thread Ted Miller


  
  
It would help if you say what kind of
  volumes you have, as they all work a little differently.
  
  You should NOT destroy the old volumes.
  
  It should be quite possible to move the bricks to a new server and
  get them running as part of THE SAME gluster system that you have
  now.
  
  Until you tell us how many bricks, how many servers have what
  bricks, exactly which servers you are replacing (you mention only
  one server, but that is not a normal gluster configuration), we
  can't give you a whole lot of help.  The usual routine involves
  working with one brick server at a time, while keeping the rest of
  the array untouched.  With some replicated arrays and some careful
  work, you don't have to take the array offline at all.  However,
  replicated arrays get handled VERY differently from distributed,
  so we can't help much until you tell us more.
  
  Ted Miller
  Elkhart, IN
  
  On 07/18/2017 06:18 AM, Andy Tai wrote:


  

  hi,  I did not see a reply to my problem.  Let me ask it
in a different way...

  
  If I have bricks from a previous glusterfs volume and that
  volume is now gone because of the old machine was replaced,
  now I tried to create a new volume and add the old bricks to
  the new volume with the "force" opinion to "volume create". 
  The old data files are still in the bricks but when I mount
  the new volume the new volume shows it is empty.
  

Is it possible for glusterfs to recognize the old data files on
the bricks in some way to essentially re-create the same view as
the old volume, via some kind of healing or meta data re-scan or
re-creation?  The bricks are in good shape with no data
corruption and are in sync (same data were replicated).  Thanks
  
  
On Thu, May 4, 2017 at 10:03 PM, Andy
  Tai 
  wrote:
  

  
Hi, I have a gluster volume with bricks spread over
  several physical drives.   I now want to upgrade my
  server to a new system and plan to move the drives
  from the old server to the new server, with a
  different host name and IP address.  Can I shut down
  the gluster volume on the old server, move and install
  the physical drives containing the bricks to the new
  server, and then create a new gluster volume on the
  new server, and add the bricks to the new volume in
  the same way reflecting the previous organization of
  the volume on the old server, and expect everything to
  work (all files preserved and accessible via
  glusterfs, with no data loss?  
  

The gluster volume on the old server would be retired
and I want to let the new server taking over the role of
serving the gluster volume.

  
  Thanks
  
  

  

  -- 

  

  

  

  

  Andy Tai, a...@atai.org,
Skype: licheng.tai,
Line: andy_tai, WeChat:
andytai1010
Year 2017 民國106年
自動的精神力是信仰與覺悟
自動的行為力是勞動與技能

  

  

  

  

  

  

  

  




-- 

  

  

  

  

  Andy Tai, a...@atai.org,
Skype: licheng.tai,

Re: [Gluster-users] set owner:group on root of volume

2017-07-18 Thread mabi

Unfortunately the root directory of my volume still get its owner and group 
resetted to root. Can someone explain why or help with this issue? I need it to 
be set to UID/GID 1000 and stay like that.
Thanks

>  Original Message 
> Subject: Re: set owner:group on root of volume
> Local Time: July 11, 2017 9:33 PM
> UTC Time: July 11, 2017 7:33 PM
> From: m...@protonmail.ch
> To: Gluster Users 
> Just found out I needed to set following two parameters:
> gluster volume set myvol storage.owner-uid 1000
> gluster volume set myvol storage.owner-gid 1000
> In case that helps any one else :)
>
>>  Original Message 
>> Subject: set owner:group on root of volume
>> Local Time: July 11, 2017 8:15 PM
>> UTC Time: July 11, 2017 6:15 PM
>> From: m...@protonmail.ch
>> To: Gluster Users 
>> Hi,
>> By default the owner and group of a GlusterFS seems to be root:root now I 
>> changed this by first mounting my volume using glusterfs/fuse on a client 
>> and did the following
>> chmod 1000:1000 /mnt/myglustervolume
>> This changed correctly the owner and group to UID/GID 1000 of my volume but 
>> like 1-2 hours later it was back to root:root. I tried again and this 
>> happens again.
>> Am I doing something wrong here? I am using GlusterFS 3.8.11 on Debian 8.
>> Regards,
>> M.___
Gluster-users mailing list
Gluster-users@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-users

Re: [Gluster-users] Sporadic Bus error on mmap() on FUSE mount

2017-07-18 Thread Niels de Vos

On Tue, Jul 18, 2017 at 01:55:17PM +0200, Jan Wrona wrote:
> On 18.7.2017 12:17, Niels de Vos wrote:
> > On Tue, Jul 18, 2017 at 10:48:45AM +0200, Jan Wrona wrote:
> > > Hi,
> > > 
> > > I need to use rrdtool on top of a Gluster FUSE mount, rrdtool uses
> > > memory-mapped file IO extensively (I know I can recompile rrdtool with
> > > mmap() disabled, but that is just a workaround). I have three FUSE mount
> > > points on three different servers, on one of them the command "rrdtool
> > > create test.rrd --start 920804400 DS:speed:COUNTER:600:U:U
> > > RRA:AVERAGE:0.5:1:24" works fine, on the other two servers the command is
> > > killed and Bus error is reported. With every Bus error, following two 
> > > lines
> > > rise in the mount log:
> > > [2017-07-18 08:30:22.470770] E [MSGID: 108008]
> > > [afr-transaction.c:2629:afr_write_txn_refresh_done] 0-flow-replicate-0:
> > > Failing FALLOCATE on gfid 6a675cdd-2ea1-473f-8765-2a4c935a22ad: 
> > > split-brain
> > > observed. [Input/output error]
> > > [2017-07-18 08:30:22.470843] W [fuse-bridge.c:1291:fuse_err_cbk]
> > > 0-glusterfs-fuse: 56589: FALLOCATE() ERR => -1 (Input/output error)
> > > 
> > > I'm not sure about current state of mmap() on FUSE and Gluster, but its
> > > strange that it works only on certain mount of the same volume.
> > This can be caused when a mmap()'d region is not written. For example,
> > trying to read/write the mmap()'d region that is after the end-of-file.
> > I've seen issues like this before (long ago), and that got fixed in the
> > write-behind xlator.
> > 
> > Could you disable the performance.write-behind option for the volume and
> > try to reproduce the problem? If the issue is in write-behind, disabling
> > it should prevent the issue.
> > 
> > If this helps, please file a bug with strace of the application and
> > tcpdump that contains the GlusterFS traffic from start to end when the
> > problem is observed.
> 
> I've disabled the performance.write-behind, umounted, stopped and started
> the volume, then mounted again, but no effect. After that I've been
> successively disabling/enabling options and xlators, and I've found that the
> problem is related to the cluster.nufa option. When NUFA translator is
> disabled, rrdtool works fine on all mounts. When enabled again, the problem
> shows up again.

Thanks for testing. NUFA is not something that is used a lot, and I
think it only has benefits for very few workloads. I dont think we can
recommend using NUFA.

In any case, this seems to be a bug in the NUFA xlator, please file a
bug for that never the less. In the bug, please point to this discussion
in the mailinglist archives.

  http://lists.gluster.org/pipermail/gluster-users/ (find the URL there)

Thanks,
Niels


> 
> > 
> >
> > https://bugzilla.redhat.com/enter_bug.cgi?product=GlusterFS=write-behind
> > 
> > HTH,
> > Niels
> > 
> > 
> > > version: glusterfs 3.10.3
> > > 
> > > [root@dc1]# gluster volume info flow
> > > Volume Name: flow
> > > Type: Distributed-Replicate
> > > Volume ID: dc6a9ea0-97ec-471f-b763-1d395ece73e1
> > > Status: Started
> > > Snapshot Count: 0
> > > Number of Bricks: 3 x 2 = 6
> > > Transport-type: tcp
> > > Bricks:
> > > Brick1: dc1.liberouter.org:/data/glusterfs/flow/brick1/safety_dir
> > > Brick2: dc2.liberouter.org:/data/glusterfs/flow/brick2/safety_dir
> > > Brick3: dc2.liberouter.org:/data/glusterfs/flow/brick1/safety_dir
> > > Brick4: dc3.liberouter.org:/data/glusterfs/flow/brick2/safety_dir
> > > Brick5: dc3.liberouter.org:/data/glusterfs/flow/brick1/safety_dir
> > > Brick6: dc1.liberouter.org:/data/glusterfs/flow/brick2/safety_dir
> > > Options Reconfigured:
> > > performance.parallel-readdir: on
> > > performance.client-io-threads: on
> > > cluster.nufa: enable
> > > network.ping-timeout: 10
> > > transport.address-family: inet
> > > nfs.disable: true
> > > 
> > > [root@dc1]# gluster volume status flow
> > > Status of volume: flow
> > > Gluster process TCP Port  RDMA Port Online  
> > > Pid
> > > --
> > > Brick dc1.liberouter.org:/data/glusterfs/fl
> > > ow/brick1/safety_dir49155 0 Y   26441
> > > Brick dc2.liberouter.org:/data/glusterfs/fl
> > > ow/brick2/safety_dir49155 0 Y   26110
> > > Brick dc2.liberouter.org:/data/glusterfs/fl
> > > ow/brick1/safety_dir49156 0 Y   26129
> > > Brick dc3.liberouter.org:/data/glusterfs/fl
> > > ow/brick2/safety_dir49152 0 Y   8703
> > > Brick dc3.liberouter.org:/data/glusterfs/fl
> > > ow/brick1/safety_dir49153 0 Y   8722
> > > Brick dc1.liberouter.org:/data/glusterfs/fl
> > > ow/brick2/safety_dir49156 0 Y   26460
> > > Self-heal Daemon on localhost   N/A   N/A Y   26493
> > > Self-heal Daemon on dc2.liberouter.org  N/A

Re: [Gluster-users] Sporadic Bus error on mmap() on FUSE mount

2017-07-18 Thread Jan Wrona


On 18.7.2017 12:17, Niels de Vos wrote:

On Tue, Jul 18, 2017 at 10:48:45AM +0200, Jan Wrona wrote:

Hi,

I need to use rrdtool on top of a Gluster FUSE mount, rrdtool uses
memory-mapped file IO extensively (I know I can recompile rrdtool with
mmap() disabled, but that is just a workaround). I have three FUSE mount
points on three different servers, on one of them the command "rrdtool
create test.rrd --start 920804400 DS:speed:COUNTER:600:U:U
RRA:AVERAGE:0.5:1:24" works fine, on the other two servers the command is
killed and Bus error is reported. With every Bus error, following two lines
rise in the mount log:
[2017-07-18 08:30:22.470770] E [MSGID: 108008]
[afr-transaction.c:2629:afr_write_txn_refresh_done] 0-flow-replicate-0:
Failing FALLOCATE on gfid 6a675cdd-2ea1-473f-8765-2a4c935a22ad: split-brain
observed. [Input/output error]
[2017-07-18 08:30:22.470843] W [fuse-bridge.c:1291:fuse_err_cbk]
0-glusterfs-fuse: 56589: FALLOCATE() ERR => -1 (Input/output error)

I'm not sure about current state of mmap() on FUSE and Gluster, but its
strange that it works only on certain mount of the same volume.

This can be caused when a mmap()'d region is not written. For example,
trying to read/write the mmap()'d region that is after the end-of-file.
I've seen issues like this before (long ago), and that got fixed in the
write-behind xlator.

Could you disable the performance.write-behind option for the volume and
try to reproduce the problem? If the issue is in write-behind, disabling
it should prevent the issue.

If this helps, please file a bug with strace of the application and
tcpdump that contains the GlusterFS traffic from start to end when the
problem is observed.


I've disabled the performance.write-behind, umounted, stopped and 
started the volume, then mounted again, but no effect. After that I've 
been successively disabling/enabling options and xlators, and I've found 
that the problem is related to the cluster.nufa option. When NUFA 
translator is disabled, rrdtool works fine on all mounts. When enabled 
again, the problem shows up again.




   
https://bugzilla.redhat.com/enter_bug.cgi?product=GlusterFS=write-behind

HTH,
Niels



version: glusterfs 3.10.3

[root@dc1]# gluster volume info flow
Volume Name: flow
Type: Distributed-Replicate
Volume ID: dc6a9ea0-97ec-471f-b763-1d395ece73e1
Status: Started
Snapshot Count: 0
Number of Bricks: 3 x 2 = 6
Transport-type: tcp
Bricks:
Brick1: dc1.liberouter.org:/data/glusterfs/flow/brick1/safety_dir
Brick2: dc2.liberouter.org:/data/glusterfs/flow/brick2/safety_dir
Brick3: dc2.liberouter.org:/data/glusterfs/flow/brick1/safety_dir
Brick4: dc3.liberouter.org:/data/glusterfs/flow/brick2/safety_dir
Brick5: dc3.liberouter.org:/data/glusterfs/flow/brick1/safety_dir
Brick6: dc1.liberouter.org:/data/glusterfs/flow/brick2/safety_dir
Options Reconfigured:
performance.parallel-readdir: on
performance.client-io-threads: on
cluster.nufa: enable
network.ping-timeout: 10
transport.address-family: inet
nfs.disable: true

[root@dc1]# gluster volume status flow
Status of volume: flow
Gluster process TCP Port  RDMA Port Online  Pid
--
Brick dc1.liberouter.org:/data/glusterfs/fl
ow/brick1/safety_dir49155 0 Y   26441
Brick dc2.liberouter.org:/data/glusterfs/fl
ow/brick2/safety_dir49155 0 Y   26110
Brick dc2.liberouter.org:/data/glusterfs/fl
ow/brick1/safety_dir49156 0 Y   26129
Brick dc3.liberouter.org:/data/glusterfs/fl
ow/brick2/safety_dir49152 0 Y   8703
Brick dc3.liberouter.org:/data/glusterfs/fl
ow/brick1/safety_dir49153 0 Y   8722
Brick dc1.liberouter.org:/data/glusterfs/fl
ow/brick2/safety_dir49156 0 Y   26460
Self-heal Daemon on localhost   N/A   N/A Y   26493
Self-heal Daemon on dc2.liberouter.org  N/A   N/A Y   26151
Self-heal Daemon on dc3.liberouter.org  N/A   N/A Y   8744

Task Status of Volume flow
--
There are no active volume tasks

___
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] moving drives containing bricks from one server to another

2017-07-18 Thread Andy Tai

hi,  I did not see a reply to my problem.  Let me ask it in a different
way...

If I have bricks from a previous glusterfs volume and that volume is now
gone because of the old machine was replaced, now I tried to create a new
volume and add the old bricks to the new volume with the "force" opinion to
"volume create".  The old data files are still in the bricks but when I
mount the new volume the new volume shows it is empty.

Is it possible for glusterfs to recognize the old data files on the bricks
in some way to essentially re-create the same view as the old volume, via
some kind of healing or meta data re-scan or re-creation?  The bricks are
in good shape with no data corruption and are in sync (same data were
replicated).  Thanks

On Thu, May 4, 2017 at 10:03 PM, Andy Tai  wrote:

> Hi, I have a gluster volume with bricks spread over several physical
> drives.   I now want to upgrade my server to a new system and plan to move
> the drives from the old server to the new server, with a different host
> name and IP address.  Can I shut down the gluster volume on the old server,
> move and install the physical drives containing the bricks to the new
> server, and then create a new gluster volume on the new server, and add the
> bricks to the new volume in the same way reflecting the previous
> organization of the volume on the old server, and expect everything to work
> (all files preserved and accessible via glusterfs, with no data loss?
>
> The gluster volume on the old server would be retired and I want to let
> the new server taking over the role of serving the gluster volume.
>
> Thanks
>
> --
> Andy Tai, a...@atai.org, Skype: licheng.tai, Line: andy_tai, WeChat:
> andytai1010
> Year 2017 民國106年
> 自動的精神力是信仰與覺悟
> 自動的行為力是勞動與技能
>

-- 
Andy Tai, a...@atai.org, Skype: licheng.tai, Line: andy_tai, WeChat:
andytai1010
Year 2017 民國106年
自動的精神力是信仰與覺悟
自動的行為力是勞動與技能
___
Gluster-users mailing list
Gluster-users@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-users

Re: [Gluster-users] Sporadic Bus error on mmap() on FUSE mount

2017-07-18 Thread Niels de Vos

On Tue, Jul 18, 2017 at 10:48:45AM +0200, Jan Wrona wrote:
> Hi,
> 
> I need to use rrdtool on top of a Gluster FUSE mount, rrdtool uses
> memory-mapped file IO extensively (I know I can recompile rrdtool with
> mmap() disabled, but that is just a workaround). I have three FUSE mount
> points on three different servers, on one of them the command "rrdtool
> create test.rrd --start 920804400 DS:speed:COUNTER:600:U:U
> RRA:AVERAGE:0.5:1:24" works fine, on the other two servers the command is
> killed and Bus error is reported. With every Bus error, following two lines
> rise in the mount log:
> [2017-07-18 08:30:22.470770] E [MSGID: 108008]
> [afr-transaction.c:2629:afr_write_txn_refresh_done] 0-flow-replicate-0:
> Failing FALLOCATE on gfid 6a675cdd-2ea1-473f-8765-2a4c935a22ad: split-brain
> observed. [Input/output error]
> [2017-07-18 08:30:22.470843] W [fuse-bridge.c:1291:fuse_err_cbk]
> 0-glusterfs-fuse: 56589: FALLOCATE() ERR => -1 (Input/output error)
> 
> I'm not sure about current state of mmap() on FUSE and Gluster, but its
> strange that it works only on certain mount of the same volume.

This can be caused when a mmap()'d region is not written. For example,
trying to read/write the mmap()'d region that is after the end-of-file.
I've seen issues like this before (long ago), and that got fixed in the
write-behind xlator.

Could you disable the performance.write-behind option for the volume and
try to reproduce the problem? If the issue is in write-behind, disabling
it should prevent the issue.

If this helps, please file a bug with strace of the application and
tcpdump that contains the GlusterFS traffic from start to end when the
problem is observed.

  
https://bugzilla.redhat.com/enter_bug.cgi?product=GlusterFS=write-behind

HTH,
Niels


> 
> version: glusterfs 3.10.3
> 
> [root@dc1]# gluster volume info flow
> Volume Name: flow
> Type: Distributed-Replicate
> Volume ID: dc6a9ea0-97ec-471f-b763-1d395ece73e1
> Status: Started
> Snapshot Count: 0
> Number of Bricks: 3 x 2 = 6
> Transport-type: tcp
> Bricks:
> Brick1: dc1.liberouter.org:/data/glusterfs/flow/brick1/safety_dir
> Brick2: dc2.liberouter.org:/data/glusterfs/flow/brick2/safety_dir
> Brick3: dc2.liberouter.org:/data/glusterfs/flow/brick1/safety_dir
> Brick4: dc3.liberouter.org:/data/glusterfs/flow/brick2/safety_dir
> Brick5: dc3.liberouter.org:/data/glusterfs/flow/brick1/safety_dir
> Brick6: dc1.liberouter.org:/data/glusterfs/flow/brick2/safety_dir
> Options Reconfigured:
> performance.parallel-readdir: on
> performance.client-io-threads: on
> cluster.nufa: enable
> network.ping-timeout: 10
> transport.address-family: inet
> nfs.disable: true
> 
> [root@dc1]# gluster volume status flow
> Status of volume: flow
> Gluster process TCP Port  RDMA Port Online  Pid
> --
> Brick dc1.liberouter.org:/data/glusterfs/fl
> ow/brick1/safety_dir49155 0 Y   26441
> Brick dc2.liberouter.org:/data/glusterfs/fl
> ow/brick2/safety_dir49155 0 Y   26110
> Brick dc2.liberouter.org:/data/glusterfs/fl
> ow/brick1/safety_dir49156 0 Y   26129
> Brick dc3.liberouter.org:/data/glusterfs/fl
> ow/brick2/safety_dir49152 0 Y   8703
> Brick dc3.liberouter.org:/data/glusterfs/fl
> ow/brick1/safety_dir49153 0 Y   8722
> Brick dc1.liberouter.org:/data/glusterfs/fl
> ow/brick2/safety_dir49156 0 Y   26460
> Self-heal Daemon on localhost   N/A   N/A Y   26493
> Self-heal Daemon on dc2.liberouter.org  N/A   N/A Y   26151
> Self-heal Daemon on dc3.liberouter.org  N/A   N/A Y   8744
> 
> Task Status of Volume flow
> --
> There are no active volume tasks
> 
> ___
> Gluster-users mailing list
> Gluster-users@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-users


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

Re: [Gluster-users] Remove and re-add bricks/peers

2017-07-18 Thread Atin Mukherjee

Wipe off /var/lib/glusterd/*

On Tue, 18 Jul 2017 at 12:48, Tom Cannaerts - INTRACTO <
tom.cannae...@intracto.com> wrote:

> We'll definitely look into upgrading this, but it's a older, legacy system
> so we need to see what we can do without breaking it.
>
> Returning to the re-adding question, what steps do I need to do to clear
> the config of the failed peers? Do I just wipe the data directory of the
> volume, or do I need to clear some other config file/folders as well?
>
> Tom
>
>
> Op ma 17 jul. 2017 om 16:39 schreef Atin Mukherjee :
>
>> That's the way. However I'd like to highlight that you're running a very
>> old gluster release. We are currently with 3.11 release which is STM and
>> the long term support is with 3.10. You should consider to upgrade to
>> atleast 3.10.
>>
>> On Mon, Jul 17, 2017 at 3:25 PM, Tom Cannaerts - INTRACTO <
>> tom.cannae...@intracto.com> wrote:
>>
>>> We had some issues with a volume. The volume is a 3 replica volume with
>>> 3 gluster 3.5.7 peers. We are now in a situation where only 1 of the 3
>>> nodes is operational. If we restart the node on one of the other nodes, the
>>> entire volume becomes unresponsive.
>>>
>>> After a lot of trial and error, we have come to the conclusion that we
>>> do not wan't to try to rejoin the other 2 nodes in the current form. We
>>> would like to completely remove them from the config of the running node,
>>> entirely reset the config on the nodes itself and then re-add them as if it
>>> was a new node, having it completely sync the volume from the working node.
>>>
>>> What would be the correct procedure for this? I assume I can use
>>> "gluster volume remove-brick" to force-remove the failed bricks from the
>>> volume and decrease the replica count, and then use "gluster peer detach"
>>> to force-remove the peers from the config, all on the currently still
>>> working node. But what do I need to do to completely clear the config and
>>> data of the failed peers? The gluster processes are currently not running
>>> on these nodes, but config + data are still present. So basically, I need
>>> to be able to clean them out before restarting them, so that they start in
>>> a clean state and not try to connect/interfere with the currently still
>>> working node.
>>>
>>> Thanks,
>>>
>>> Tom
>>>
>>>
>>> --
>>> Met vriendelijke groeten,
>>> Tom Cannaerts
>>>
>>>
>>> *Service and MaintenanceIntracto - digital agency*
>>>
>>> Zavelheide 15 - 2200 Herentals
>>> Tel: +32 14 28 29 29
>>> www.intracto.com
>>>
>>>
>>> Ben je tevreden over deze e-mail?
>>>
>>> 
>>>
>>> 
>>>
>>> 
>>>
>>> 
>>>
>>> 
>>>
>>> ___
>>> Gluster-users mailing list
>>> Gluster-users@gluster.org
>>> http://lists.gluster.org/mailman/listinfo/gluster-users
>>>
>>
>> --
> Met vriendelijke groeten,
> Tom Cannaerts
>
>
> *Service and MaintenanceIntracto - digital agency*
>
> Zavelheide 15 - 2200 Herentals
> Tel: +32 14 28 29 29
> www.intracto.com
>
>
> Ben je tevreden over deze e-mail?
>
> 
> 
> 
> 
> 
>
-- 
- Atin (atinm)
___
Gluster-users mailing list
Gluster-users@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-users

[Gluster-users] Sporadic Bus error on mmap() on FUSE mount

2017-07-18 Thread Jan Wrona


Hi,

I need to use rrdtool on top of a Gluster FUSE mount, rrdtool uses 
memory-mapped file IO extensively (I know I can recompile rrdtool with 
mmap() disabled, but that is just a workaround). I have three FUSE mount 
points on three different servers, on one of them the command "rrdtool 
create test.rrd --start 920804400 DS:speed:COUNTER:600:U:U 
RRA:AVERAGE:0.5:1:24" works fine, on the other two servers the command 
is killed and Bus error is reported. With every Bus error, following two 
lines rise in the mount log:
[2017-07-18 08:30:22.470770] E [MSGID: 108008] 
[afr-transaction.c:2629:afr_write_txn_refresh_done] 0-flow-replicate-0: 
Failing FALLOCATE on gfid 6a675cdd-2ea1-473f-8765-2a4c935a22ad: 
split-brain observed. [Input/output error]
[2017-07-18 08:30:22.470843] W [fuse-bridge.c:1291:fuse_err_cbk] 
0-glusterfs-fuse: 56589: FALLOCATE() ERR => -1 (Input/output error)


I'm not sure about current state of mmap() on FUSE and Gluster, but its 
strange that it works only on certain mount of the same volume.


version: glusterfs 3.10.3

[root@dc1]# gluster volume info flow
Volume Name: flow
Type: Distributed-Replicate
Volume ID: dc6a9ea0-97ec-471f-b763-1d395ece73e1
Status: Started
Snapshot Count: 0
Number of Bricks: 3 x 2 = 6
Transport-type: tcp
Bricks:
Brick1: dc1.liberouter.org:/data/glusterfs/flow/brick1/safety_dir
Brick2: dc2.liberouter.org:/data/glusterfs/flow/brick2/safety_dir
Brick3: dc2.liberouter.org:/data/glusterfs/flow/brick1/safety_dir
Brick4: dc3.liberouter.org:/data/glusterfs/flow/brick2/safety_dir
Brick5: dc3.liberouter.org:/data/glusterfs/flow/brick1/safety_dir
Brick6: dc1.liberouter.org:/data/glusterfs/flow/brick2/safety_dir
Options Reconfigured:
performance.parallel-readdir: on
performance.client-io-threads: on
cluster.nufa: enable
network.ping-timeout: 10
transport.address-family: inet
nfs.disable: true

[root@dc1]# gluster volume status flow
Status of volume: flow
Gluster process TCP Port  RDMA Port Online  Pid
--
Brick dc1.liberouter.org:/data/glusterfs/fl
ow/brick1/safety_dir49155 0 Y   26441
Brick dc2.liberouter.org:/data/glusterfs/fl
ow/brick2/safety_dir49155 0 Y   26110
Brick dc2.liberouter.org:/data/glusterfs/fl
ow/brick1/safety_dir49156 0 Y   26129
Brick dc3.liberouter.org:/data/glusterfs/fl
ow/brick2/safety_dir49152 0 Y   8703
Brick dc3.liberouter.org:/data/glusterfs/fl
ow/brick1/safety_dir49153 0 Y   8722
Brick dc1.liberouter.org:/data/glusterfs/fl
ow/brick2/safety_dir49156 0 Y   26460
Self-heal Daemon on localhost   N/A   N/A Y   26493
Self-heal Daemon on dc2.liberouter.org  N/A   N/A Y   26151
Self-heal Daemon on dc3.liberouter.org  N/A   N/A Y   8744

Task Status of Volume flow
--
There are no active volume tasks

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

Re: [Gluster-users] Bug 1374166 or similar

2017-07-18 Thread Bernhard Dübi

Hi Jiffin,

thank you for the explanation

Kind Regards
Bernhard

2017-07-18 8:53 GMT+02:00 Jiffin Tony Thottan :
>
>
> On 16/07/17 20:11, Bernhard Dübi wrote:
>>
>> Hi,
>>
>> both Gluster servers were rebooted and now the unlink directory is clean.
>
>
> Following should have happened, If delete operation is performed gluster
> keeps file in .unlink directory if it has open fd.
> In this case since lazy umount is performed, ganesha server may still keep
> the fd's open by that client so gluster keeps
> the unlink directory even though it is removed from fuse mount.
>
> --
> Jiffin
>
>
>> Best Regards
>> Bernhard
>>
>> 2017-07-14 12:43 GMT+02:00 Bernhard Dübi <1linuxengin...@gmail.com>:
>>>
>>> Hi,
>>>
>>> yes, I mounted the Gluster volume and deleted the files from the
>>> volume not the brick
>>>
>>> mount -t glusterfs hostname:volname /mnt
>>> cd /mnt/some/directory
>>> rm -rf *
>>>
>>> restart of nfs-ganesha is planned for tomorrow. I'll keep you posted
>>> BTW: nfs-ganesha is running on a separate server in standalone
>>> configuration
>>>
>>> Best Regards
>>> Bernhard
>>>
>>> 2017-07-14 10:43 GMT+02:00 Jiffin Tony Thottan :


 On 14/07/17 13:06, Bernhard Dübi wrote:
>
> Hello everybody,
>
> I'm in a similar situation as described in
> https://bugzilla.redhat.com/show_bug.cgi?id=1374166


 The issue got fixed by https://review.gluster.org/#/c/14820 and is
 already
 available in 3.8 branch

> I have a gluster volume exported through ganesha. we had some problems
> on the gluster server and the NFS mount on the client was hanging.
> I did a lazy umount of the NFS mount on the client, then went to the
> Gluster server, mounted the Gluster volume and deleted a bunch of
> files.
> When I mounted the volume again on the client I noticed that the space
> was not freed. Now I find them in $brick/.glusterfs/unlink

 Here you have mounted the volume via glusterfs fuse mount and deleted
 those
 files
 right(not directly from the bricks)?
 Can you restart nfs-ganesha server and see what happens ?
 What type of volume are you using?
 --
 Jiffin

> OS: Ubuntu 16.04
> Gluster: 3.8.13
> Ganesha: 2.4.5
>
> Let me know if you need more info
>
> Best Regards
> Bernhard
> ___
> 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] Remove and re-add bricks/peers

2017-07-18 Thread Tom Cannaerts - INTRACTO

We'll definitely look into upgrading this, but it's a older, legacy system
so we need to see what we can do without breaking it.

Returning to the re-adding question, what steps do I need to do to clear
the config of the failed peers? Do I just wipe the data directory of the
volume, or do I need to clear some other config file/folders as well?

Tom


Op ma 17 jul. 2017 om 16:39 schreef Atin Mukherjee :

> That's the way. However I'd like to highlight that you're running a very
> old gluster release. We are currently with 3.11 release which is STM and
> the long term support is with 3.10. You should consider to upgrade to
> atleast 3.10.
>
> On Mon, Jul 17, 2017 at 3:25 PM, Tom Cannaerts - INTRACTO <
> tom.cannae...@intracto.com> wrote:
>
>> We had some issues with a volume. The volume is a 3 replica volume with 3
>> gluster 3.5.7 peers. We are now in a situation where only 1 of the 3 nodes
>> is operational. If we restart the node on one of the other nodes, the
>> entire volume becomes unresponsive.
>>
>> After a lot of trial and error, we have come to the conclusion that we do
>> not wan't to try to rejoin the other 2 nodes in the current form. We would
>> like to completely remove them from the config of the running node,
>> entirely reset the config on the nodes itself and then re-add them as if it
>> was a new node, having it completely sync the volume from the working node.
>>
>> What would be the correct procedure for this? I assume I can use "gluster
>> volume remove-brick" to force-remove the failed bricks from the volume and
>> decrease the replica count, and then use "gluster peer detach" to
>> force-remove the peers from the config, all on the currently still working
>> node. But what do I need to do to completely clear the config and data of
>> the failed peers? The gluster processes are currently not running on these
>> nodes, but config + data are still present. So basically, I need to be able
>> to clean them out before restarting them, so that they start in a clean
>> state and not try to connect/interfere with the currently still working
>> node.
>>
>> Thanks,
>>
>> Tom
>>
>>
>> --
>> Met vriendelijke groeten,
>> Tom Cannaerts
>>
>>
>> *Service and MaintenanceIntracto - digital agency*
>>
>> Zavelheide 15 - 2200 Herentals
>> Tel: +32 14 28 29 29
>> www.intracto.com
>>
>>
>> Ben je tevreden over deze e-mail?
>>
>> 
>> 
>> 
>> 
>> 
>>
>> ___
>> Gluster-users mailing list
>> Gluster-users@gluster.org
>> http://lists.gluster.org/mailman/listinfo/gluster-users
>>
>
> --
Met vriendelijke groeten,
Tom Cannaerts


*Service and MaintenanceIntracto - digital agency*

Zavelheide 15 - 2200 Herentals
Tel: +32 14 28 29 29
www.intracto.com


Ben je tevreden over deze e-mail?






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

Re: [Gluster-users] Bug 1374166 or similar

2017-07-18 Thread Jiffin Tony Thottan




On 16/07/17 20:11, Bernhard Dübi wrote:

Hi,

both Gluster servers were rebooted and now the unlink directory is clean.


Following should have happened, If delete operation is performed gluster 
keeps file in .unlink directory if it has open fd.
In this case since lazy umount is performed, ganesha server may still 
keep the fd's open by that client so gluster keeps

the unlink directory even though it is removed from fuse mount.

--
Jiffin


Best Regards
Bernhard

2017-07-14 12:43 GMT+02:00 Bernhard Dübi <1linuxengin...@gmail.com>:

Hi,

yes, I mounted the Gluster volume and deleted the files from the
volume not the brick

mount -t glusterfs hostname:volname /mnt
cd /mnt/some/directory
rm -rf *

restart of nfs-ganesha is planned for tomorrow. I'll keep you posted
BTW: nfs-ganesha is running on a separate server in standalone configuration

Best Regards
Bernhard

2017-07-14 10:43 GMT+02:00 Jiffin Tony Thottan :


On 14/07/17 13:06, Bernhard Dübi wrote:

Hello everybody,

I'm in a similar situation as described in
https://bugzilla.redhat.com/show_bug.cgi?id=1374166


The issue got fixed by https://review.gluster.org/#/c/14820 and is already
available in 3.8 branch


I have a gluster volume exported through ganesha. we had some problems
on the gluster server and the NFS mount on the client was hanging.
I did a lazy umount of the NFS mount on the client, then went to the
Gluster server, mounted the Gluster volume and deleted a bunch of
files.
When I mounted the volume again on the client I noticed that the space
was not freed. Now I find them in $brick/.glusterfs/unlink

Here you have mounted the volume via glusterfs fuse mount and deleted those
files
right(not directly from the bricks)?
Can you restart nfs-ganesha server and see what happens ?
What type of volume are you using?
--
Jiffin


OS: Ubuntu 16.04
Gluster: 3.8.13
Ganesha: 2.4.5

Let me know if you need more info

Best Regards
Bernhard
___
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] moving drives containing bricks from one server to another

Re: [Gluster-users] set owner:group on root of volume

Re: [Gluster-users] Sporadic Bus error on mmap() on FUSE mount

Re: [Gluster-users] Sporadic Bus error on mmap() on FUSE mount

Re: [Gluster-users] moving drives containing bricks from one server to another

Re: [Gluster-users] Sporadic Bus error on mmap() on FUSE mount

Re: [Gluster-users] Remove and re-add bricks/peers

[Gluster-users] Sporadic Bus error on mmap() on FUSE mount

Re: [Gluster-users] Bug 1374166 or similar

Re: [Gluster-users] Remove and re-add bricks/peers

Re: [Gluster-users] Bug 1374166 or similar

11 matches

Site Navigation

Mail list logo

Footer information