search for: 9bda

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/brick/....

...urrent 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 17:4...

...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. So...

...t 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: > 8394...

...ile 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 Blocks: 1...

...e 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/.glusterfs/...

...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? >>...

...s > 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 b...

...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 happene...

...d. > 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-9...

Hi! I used to have arch linux running on 1 btrfs partition (sda1, incl. /boot). When switching to 3.2.5 recently the system fails to boot: (after udevd) /etc/rc.sysinit: line 15: 117 Bus error mountpoint -q /proc and so on, no idea. It used to boot with 3.2.4, but 1) I obviously had some corruption in the tree, when I tried to delete a certain file I hit e.g. "kernel BUG at