search for: 41cc

Now I understand what you mean the the "-samefile" parameter of "find". As requested I have now run the following command on all 3 nodes with the ouput of all 3 nodes below: sudo find /data/myvolume/brick -samefile /data/myvolume/brick/.glusterfs/29/e0/29e0d13e-1217-41cc-9bda-1fbbf781c397 -ls node1: 8404683 0 lrwxrwxrwx 1 root root 66 Jul 27 15:43 /data/myvolume/brick/.glusterfs/29/e0/29e0d13e-1217-41cc-9bda-1fbbf781c397 -> ../../fe/c0/fec0e4f4-38d2-4e2e-b5db-fdc0b9b54810/OC_DEFAULT_MODULE node2: 8394638 0 lrwxrwxrwx 1 root root 66 Jul 27 15:43 /data/myvolume/br...

...my current situation: on node2 I have found the following file xattrop/indices file which matches the GFID of the "heal info" command (below is there output of "ls -lai": 2798404 ---------- 2 root root 0 Apr 28 22:51 /data/myvolume/brick/.glusterfs/indices/xattrop/29e0d13e-1217-41cc-9bda-1fbbf781c397 As you can see this file has inode number 2798404, so I ran the following command on all my nodes (node1, node2 and arbiternode): sudo find /data/myvolume/brick -inum 2798404 -ls Here below are the results for all 3 nodes: node1: 2798404 19 -rw-r--r-- 2 www-data www-data 32 Jun 19...

...de2 I have found the following file xattrop/indices file which > matches the GFID of the "heal info" command (below is there output of > "ls -lai": > > 2798404 ---------- 2 root root 0 Apr 28 22:51 > /data/myvolume/brick/.glusterfs/indices/xattrop/29e0d13e-1217-41cc-9bda-1fbbf781c397 > > > > As you can see this file has inode number 2798404, so I ran the > following command on all my nodes (node1, node2 and arbiternode): ...which is what I was saying is incorrect. 2798404 is an XFS inode number and is not common to the same file across nodes...

...d what you mean the the "-samefile" parameter of > "find". As requested I have now run the following command on all 3 > nodes with the ouput of all 3 nodes below: > > sudo find /data/myvolume/brick -samefile > /data/myvolume/brick/.glusterfs/29/e0/29e0d13e-1217-41cc-9bda-1fbbf781c397 > -ls > > node1: > 8404683 0 lrwxrwxrwx 1 root root 66 Jul 27 15:43 > /data/myvolume/brick/.glusterfs/29/e0/29e0d13e-1217-41cc-9bda-1fbbf781c397 > -> ../../fe/c0/fec0e4f4-38d2-4e2e-b5db-fdc0b9b54810/OC_DEFAULT_MODULE > > node2: >...

...log file after running the above command. I checked the files which need to be healing using the "heal <volume> info" command and it still shows that very same GFID on node2 to be healed. So nothing changed here. The file /data/myvolume/brick/.glusterfs/indices/xattrop/29e0d13e-1217-41cc-9bda-1fbbf781c397 is only on node2 and not on my nod1 nor on my arbiternode. This file seems to be a regular file and not a symlink. Here is the output of the stat command on it from my node2: File: ?/data/myvolume/brick/.glusterfs/indices/xattrop/29e0d13e-1217-41cc-9bda-1fbbf781c397? Size: 0 Block...

...or the fact that there is one single file which needs healing and does not get healed as you can see here from the output of a "heal info": Brick node1.domain.tld:/data/myvolume/brick Status: Connected Number of entries: 0 Brick node2.domain.tld:/data/myvolume/brick <gfid:29e0d13e-1217-41cc-9bda-1fbbf781c397> Status: Connected Number of entries: 1 Brick arbiternode.domain.tld:/srv/glusterfs/myvolume/brick Status: Connected Number of entries: 0 On my node2 the respective .glusterfs/indices/xattrop directory contains two files as you can see below: ls -lai /data/myvolume/brick/.glust...

...after running the above command. I checked the files which need to be healing using the "heal <volume> info" command and it still shows that very same GFID on node2 to be healed. So nothing changed here. >> The file /data/myvolume/brick/.glusterfs/indices/xattrop/29e0d13e-1217-41cc-9bda-1fbbf781c397 is only on node2 and not on my nod1 nor on my arbiternode. This file seems to be a regular file and not a symlink. Here is the output of the stat command on it from my node2: >> File: ?/data/myvolume/brick/.glusterfs/indices/xattrop/29e0d13e-1217-41cc-9bda-1fbbf781c397? >...

...needs > healing and does not get healed as you can see here from the output of > a "heal info": > > Brick node1.domain.tld:/data/myvolume/brick > Status: Connected > Number of entries: 0 > > Brick node2.domain.tld:/data/myvolume/brick > <gfid:29e0d13e-1217-41cc-9bda-1fbbf781c397> > Status: Connected > Number of entries: 1 > > Brick arbiternode.domain.tld:/srv/glusterfs/myvolume/brick > Status: Connected > Number of entries: 0 > > On my node2 the respective .glusterfs/indices/xattrop directory > contains two files as you can...

...Here is an ls > -lai of the file itself on node1: Sorry I don't understand, isn't that (XFS) inode number specific to node2's brick? If you want to use the same command, maybe you should try `find /data/myvolume/brick -samefile /data/myvolume/brick/.glusterfs/29/e0/29e0d13e-1217-41cc-9bda-1fbbf781c397` on all 3 bricks. > > -rw-r--r-- 1 www-data www-data 32 Jun 19 17:42 fileKey > > As you can see it is a 32 bytes file and as you suggested I ran a > "stat" on this very same file through a glusterfs mount (using fuse) > but unfortunately nothing ha...

...ommand. > I checked the files which need to be healing using the "heal <volume> > info" command and it still shows that very same GFID on node2 to be > healed. So nothing changed here. > > The file > /data/myvolume/brick/.glusterfs/indices/xattrop/29e0d13e-1217-41cc-9bda-1fbbf781c397 > is only on node2 and not on my nod1 nor on my arbiternode. This file > seems to be a regular file and not a symlink. Here is the output of > the stat command on it from my node2: > > File: > ?/data/myvolume/brick/.glusterfs/indices/xattrop/29e0d13e-1217-4...

...ultiboot /xen-4.6.0-2.el7.gz placeholder dom0_mem=1024M,max:1024M cpuinfo com1=115200,8n1 console=com1,tty loglvl=all guest_loglvl=all ${xen_rm_opts} echo 'Loading Linux 3.18.21-16.el7.x86_64 ...' module /vmlinuz-3.18.21-16.el7.x86_64 placeholder root=UUID=9dc18146-f9b3-41cc-ba9c-7314689abcde ro crashkernel=auto debug irqpoll ipv6.disable=1 console=hvc0 earlyprintk=xen nomodeset echo 'Loading initial ramdisk ...' module --nounzip /initramfs-3.18.21-16.el7.x86_64.img What I have tried: 1) adding debug into the vmlinuz line 2) disabling i...

....gz placeholder dom0_mem=1024M,max:1024M > cpuinfo com1=115200,8n1 console=com1,tty loglvl=all guest_loglvl=all > ${xen_rm_opts} > echo 'Loading Linux 3.18.21-16.el7.x86_64 ...' > module /vmlinuz-3.18.21-16.el7.x86_64 placeholder > root=UUID=9dc18146-f9b3-41cc-ba9c-7314689abcde ro crashkernel=auto debug > irqpoll ipv6.disable=1 console=hvc0 earlyprintk=xen nomodeset > echo 'Loading initial ramdisk ...' > module --nounzip /initramfs-3.18.21-16.el7.x86_64.img > > > What I have tried: > > 1) adding debug...

...ultiboot /xen-4.6.0-2.el7.gz placeholder? dom0_mem=1024M,max:1024M cpuinfo com1=115200,8n1 console=com1,tty loglvl=all guest_loglvl=all ${xen_rm_opts} ? ? ? ? echo? ? 'Loading Linux 3.18.21-16.el7.x86_64 ...' ? ? ? ? module? /vmlinuz-3.18.21-16.el7.x86_64 placeholder root=UUID=9dc18146-f9b3-41cc-ba9c-7314689abcde ro crashkernel=auto debug irqpoll ipv6.disable=1 console=hvc0 earlyprintk=xen nomodeset ? ? ? ? echo? ? 'Loading initial ramdisk ...' ? ? ? ? module? --nounzip ? /initramfs-3.18.21-16.el7.x86_64.img What I have tried: 1) adding debug into the vmlinuz line 2) disabling i...

...check_host call: root@# mdb -p `pgrep rpc.metad` Loading modules: [ ld.so.1 libc.so.1 libnvpair.so.1 libuutil.so.1 libavl.so.1 ] > check_host:b > :c mdb: stop at check_host mdb: target stopped at: check_host: save %sp, -0x68, %sp > $c check_host(ffbff930, 3dd50, 2e800, 2e800, 41cc, 4000) svc_init+0x88(3c650, 2, ffbff930, 2ee78, ffbff934, 2ec00) mdrpc_lock_set_common+0x58(ffbff970, ffbff928, 3c650, 2ec00, 2ee78, ffbff930) metad_2+0x5e4(3c650, 3d9c8, 1b82c, 2e634, 2e400, 2e718) libnsl.so.1`_svc_prog_dispatch+0x184(3d9c8, 3c778, 3c650, 2, 1b8d8, 1) libnsl.so.1`svc_getreq_commo...

First off thanks very much for all the hard work on unicorn. Alas, we''ve encountered an issue where unicorn fails to spawn new workers that have loaded the incoming revision on a capistrano deploy. I''m not entirely sure the issue is due to unicorn as it appears that bundler was responsible for a similar issue in the past: