similar to: Sent and Received peer request (Connected)

On Fri, 12 Jan 2018 at 01:34, Dj Merrill <gluster at deej.net> wrote: > This morning I did a rolling update from the latest 3.7.x to 3.12.4, > with no client activity. "Rolling" as in, shut down the Gluster > services on the first server, update, reboot, wait until up and running, > proceed to the next server. I anticipated that a 3.12 server might not > properly

Hi, To test corruption detection and repair, we modified a file inside the brick directory on server glusterfs1, and scheduled regular scrubs. The corruption is detected: Error count: 1 Corrupted object's [GFID]: 9be5eecf-5ad8-4256-8b08-879aecf65881 ==> BRICK: /data/brick1/gv0 path: /prd/drupal-files-prd/inline-images/small - main building 1_0.jpg We have self-healing enabled, and

We lost the attributes on all the bricks on servers glusterfs2 and glusterfs3 again. [root at glusterfs2 Log_Files]# gluster volume info Volume Name: StoragePool Type: Distributed-Disperse Volume ID: 149e976f-4e21-451c-bf0f-f5691208531f Status: Started Number of Bricks: 20 x (2 + 1) = 60 Transport-type: tcp Bricks: Brick1: glusterfs1sds:/ws/disk1/ws_brick Brick2: glusterfs2sds:/ws/disk1/ws_brick

On Fri, Jul 7, 2017 at 9:25 PM, Ankireddypalle Reddy <areddy at commvault.com> wrote: > 3.7.19 > These are the only callers for removexattr and only _posix_remove_xattr has the potential to do removexattr as posix_removexattr already makes sure that it is not gfid/volume-id. And surprise surprise _posix_remove_xattr happens only from healing code of afr/ec. And this can only happen

Hello subscribers, I have a very strange question regarding SSL setup on gluster storage. I have create a common CA and sign certificate for my gluster nodes, placed host certificate, key and common CA certificate into /etc/ssl/, create a file called secure-access into /var/lib/glusterd/ Then, I start glusterd on all nodes, system work fine, I see with peer status all of my nodes. No problem.

Ram, As per the code, self-heal was the only candidate which *can* do it. Could you check logs of self-heal daemon and the mount to check if there are any metadata heals on root? +Sanoj Sanoj, Is there any systemtap script we can use to detect which process is removing these xattrs? On Sat, Jul 8, 2017 at 2:58 AM, Ankireddypalle Reddy <areddy at commvault.com> wrote: >

Please use the systemtap script( https://paste.fedoraproject.org/paste/EGDa0ErwX0LV3y-gBYpfNA) to check which process is invoking remove xattr calls. It prints the pid, tid and arguments of all removexattr calls. I have checked for these fops at the protocol/client and posix translators. To run the script .. 1) install systemtap and dependencies. 2) install glusterfs-debuginfo 3) change the path

@ pranith , yes . we can get the pid on all removexattr call and also print the backtrace of the glusterfsd process when trigerring removing xattr. I will write the script and reply back. On Sat, Jul 8, 2017 at 7:06 AM, Pranith Kumar Karampuri <pkarampu at redhat.com > wrote: > Ram, > As per the code, self-heal was the only candidate which *can* do > it. Could you check

Thanks for the swift turn around. Will try this out and let you know. Thanks and Regards, Ram From: Pranith Kumar Karampuri [mailto:pkarampu at redhat.com] Sent: Monday, July 10, 2017 8:31 AM To: Sanoj Unnikrishnan Cc: Ankireddypalle Reddy; Gluster Devel (gluster-devel at gluster.org); gluster-users at gluster.org Subject: Re: [Gluster-devel] gfid and volume-id extended attributes lost Ram,

Ram, If you see it again, you can use this. I am going to send out a patch for the code path which can lead to removal of gfid/volume-id tomorrow. On Mon, Jul 10, 2017 at 5:19 PM, Sanoj Unnikrishnan <sunnikri at redhat.com> wrote: > Please use the systemtap script(https://paste.fedoraproject.org/paste/ > EGDa0ErwX0LV3y-gBYpfNA) to check which process is invoking remove xattr

Ram, I sent https://review.gluster.org/17765 to fix the possibility in bulk removexattr. But I am not sure if this is indeed the reason for this issue. On Mon, Jul 10, 2017 at 6:30 PM, Ankireddypalle Reddy <areddy at commvault.com> wrote: > Thanks for the swift turn around. Will try this out and let you know. > > > > Thanks and Regards, > > Ram > > *From:*

The PJSIP endpoint is configured for ulaw only. Not sure how or why we are seeing the g729 on calls for this endpoint. Would this be a case that asterisk detects the rtp stream is g729 even though it's negotiated as ulaw? Why would asterisk change the format to g729 when disallow = all and allow = ulaw are the endpoint settings? [121] type = endpoint context = IS transport = transport1 aors

? Fri, 22 Mar 2024 14:31:17 -0500 Val <valkremk at gmail.com> ?????: > How do I get the first few bytes? What does file.info('X1.RData') say? Do you get any output if you run print(readBin('X1.RData', raw(), 128))? If this is happening on a Linux or macOS machine, the operating system command xxd -l 128 X1.RData will give the same output in a more readable manner,

Here is the first few bytes, xxd -l 128 X1.RData 00000000: 8d5a 35f8 1ac5 cc14 a04e be5c 572f a3ad .Z5......N.\W/.. 00000010: 6210 7024 9b58 93c7 34d0 acb7 7a82 3f99 b.p$.X..4...z.?. 00000020: 66ce 0ebb 2057 ec36 55b4 0ece a036 695a f... W.6U....6iZ 00000030: 258b 3493 b661 f620 f7fe ada7 158a 15f7 %.4..a. ........ 00000040: e016 a548 6fcb 20c8 6fb4 493d adc9 ea4a ...Ho. .o.I=...J 00000050:

Same error here... root at samba01:~# samba-tool ldapcmp ldap://samba01 ldap://samba02 -Uadministrator --filter=CN,DC,member CONFIGURATION Password for [LAURENZ\administrator]: * Comparing [CONFIGURATION] context... * Objects to be compared: 1631 Comparing: 'CN=SAMBA03,CN=Servers,CN=Harz,CN=Sites,CN=Configuration,DC=local,DC=laurenz,DC=ws' [ldap://samba01]

Hey Richard, Could you share the following informations please? 1. gluster volume info <volname> 2. getfattr output of that file from all the bricks getfattr -d -e hex -m . <brickpath/filepath> 3. glustershd & glfsheal logs Regards, Karthik On Thu, Oct 26, 2017 at 10:21 AM, Amar Tumballi <atumball at redhat.com> wrote: > On a side note, try recently released health

On a side note, try recently released health report tool, and see if it does diagnose any issues in setup. Currently you may have to run it in all the three machines. On 26-Oct-2017 6:50 AM, "Amar Tumballi" <atumball at redhat.com> wrote: > Thanks for this report. This week many of the developers are at Gluster > Summit in Prague, will be checking this and respond next

Hi Karthik, thanks for taking a look at this. I'm not working with gluster long enough to make heads or tails out of the logs. The logs are attached to this mail and here is the other information: # gluster volume info home Volume Name: home Type: Replicate Volume ID: fe6218ae-f46b-42b3-a467-5fc6a36ad48a Status: Started Snapshot Count: 1 Number of Bricks: 1 x 3 = 3 Transport-type: tcp