similar to: how to verify bitrot signed file manually?

resending mail. On Fri, Sep 22, 2017 at 5:30 PM, Amudhan P <amudhan83 at gmail.com> wrote: > ok, from bitrot code I figured out gluster using sha256 hashing algo. > > > Now coming to the problem, during scrub run in my cluster some of my files > were marked as bad in few set of nodes. > I just wanted to confirm bad file. so, I have used "sha256sum" tool in >

my volume is distributed disperse volume 8+2 EC. file1 and file2 are different files lying in same brick. I am able to read the file from mount point without any issue because of EC it reads rest of the available blocks in other nodes. my question is "file1" sha256 value matches bitrot signature value but still, it is also marked as bad by scrubber daemon. why is that? On Fri, Sep

ok, from bitrot code I figured out gluster using sha256 hashing algo. Now coming to the problem, during scrub run in my cluster some of my files were marked as bad in few set of nodes. I just wanted to confirm bad file. so, I have used "sha256sum" tool in Linux to manually get file hash. here is the result. file-1, file-2 marked as bad by scrub and file-3 is healthy. file-1 sha256

Hi Amudhan, Sorry for the late response as I was busy with other things. You are right bitrot uses sha256 for checksum. If file-1, file-2 are marked bad, the I/O should be errored out with EIO. If that is not happening, we need to look further into it. But what's the file contents of file-1 and file-2 on the replica bricks ? Are they matching ? Thanks and Regards, Kotresh HR On Mon, Sep 25,

Any update? On Fri, Oct 13, 2017 at 1:14 PM, Amudhan P <amudhan83 at gmail.com> wrote: > any update?. > > why is it marked bad? > > Any way to find out what happened to the file? > > > On Tue, Oct 3, 2017 at 12:44 PM, Amudhan P <amudhan83 at gmail.com> wrote: > >> >> my volume is distributed disperse volume 8+2 EC. >> file1 and file2 are

I remember we have fixed 2 issues where such kind of error messages were coming and also we were seeing issues on mount. In one of the case the problem was in dht. Unfortunately, I don't remember the BZ's for those issues. As glusterfs 3.10.1 is an old version, I would request you to please upgrade it to latest one. I am sure this would have fix . ---- Ashish ----- Original

Hi Nithya, I have checked gfid in all the bricks in disperse set for the folder. it all same there is no difference. regards Amudhan P On Fri, Nov 10, 2017 at 9:02 AM, Nithya Balachandran <nbalacha at redhat.com> wrote: > Hi, > > Comments inline. > > Regards, > Nithya > > On 9 November 2017 at 15:05, Amudhan Pandian <amudh_an at hotmail.com> wrote: >

On 14 November 2017 at 08:36, Ashish Pandey <aspandey at redhat.com> wrote: > > I remember we have fixed 2 issues where such kind of error messages were > coming and also we were seeing issues on mount. > In one of the case the problem was in dht. Unfortunately, I don't > remember the BZ's for those issues. > I think the DHT BZ you are referring to 1438423

Adding Ashish . Hi Amudhan, Can you check the gfids for every dir in that heirarchy? Maybe one of the parent dirs has a gfid mismatch. Regards, Nithya On 13 November 2017 at 17:39, Amudhan P <amudhan83 at gmail.com> wrote: > Hi Nithya, > > I have checked gfid in all the bricks in disperse set for the folder. it > all same there is no difference. > > regards >

resending mail from another id, doubt on whether mail reaches mailing list. ---------- Forwarded message ---------- From: Amudhan P <amudhan83 at gmail.com<mailto:amudhan83 at gmail.com>> Date: Tue, Nov 7, 2017 at 6:43 PM Subject: error logged in fuse-mount log file To: Gluster Users <gluster-users at gluster.org<mailto:gluster-users at gluster.org>> Hi, I am using

Hi, Comments inline. Regards, Nithya On 9 November 2017 at 15:05, Amudhan Pandian <amudh_an at hotmail.com> wrote: > resending mail from another id, doubt on whether mail reaches mailing list. > > > ---------- Forwarded message ---------- > From: *Amudhan P* <amudhan83 at gmail.com> > Date: Tue, Nov 7, 2017 at 6:43 PM > Subject: error logged in fuse-mount log

Based on this BZ https://bugzilla.redhat.com/show_bug.cgi?id=1414287 it has been fixed in glusterfs-3.11.0 --- Ashish ----- Original Message ----- From: "Amudhan P" <amudhan83 at gmail.com> To: "Ashish Pandey" <aspandey at redhat.com> Cc: "Gluster Users" <gluster-users at gluster.org> Sent: Thursday, August 31, 2017 1:07:16 PM Subject:

Ashish, which version has this issue fixed? On Tue, Aug 29, 2017 at 6:38 PM, Amudhan P <amudhan83 at gmail.com> wrote: > I am using 3.10.1 from which version this update is available. > > > On Tue, Aug 29, 2017 at 5:03 PM, Ashish Pandey <aspandey at redhat.com> > wrote: > >> >> Whenever we do some fop on EC volume on a file, we check the xattr also

I am using 3.10.1 from which version this update is available. On Tue, Aug 29, 2017 at 5:03 PM, Ashish Pandey <aspandey at redhat.com> wrote: > > Whenever we do some fop on EC volume on a file, we check the xattr also to > see if the file is healthy or not. If not, we trigger heal. > lookup is the fop for which we don't take inodelk lock so it is possible > that the

Hi Amudhan, Please go through the following that would clarify up-gradation concerns from DHT to RIO in 4.0 1. RIO would not deprecate DHT. Both DHT and RIO would co-exist. 2. DHT volumes would not be migrated to RIO. DHT volumes would still be using DHT code. 3. The new volume creation should specifically opt for RIO volume once RIO is in place. 4. RIO should be perceived as

Whenever we do some fop on EC volume on a file, we check the xattr also to see if the file is healthy or not. If not, we trigger heal. lookup is the fop for which we don't take inodelk lock so it is possible that the xattr which we get for lookup fop are different for some bricks. This difference is not reliable but still we are triggering heal and that is why you are seeing these messages.

Hi , I need some clarification for below error msg in the glustershd.log file. What is this msg? Why is this showing up?. currently using glusterfs 3.10.1 when ever I start write process to volume (volume mounted thru fuse) I am seeing this kind of error and glustershd process consumes some percentage of cpu until write process completes. [2017-08-28 10:01:13.030710] W [MSGID: 122006]

does RIO improves folder listing and rebalance, when compared to 3.x? if yes, do you have any performance data comparing RIO and DHT? On Thu, Nov 2, 2017 at 4:12 PM, Kaushal M <kshlmster at gmail.com> wrote: > On Thu, Nov 2, 2017 at 4:00 PM, Amudhan P <amudhan83 at gmail.com> wrote: > > if doing an upgrade from 3.10.1 to 4.0 or 4.1, will I be able to access > > volume

Hi I've got a problem on a EC volume where heal doesn't seem to work for just few files (heal info shows no progress for few days, Warning on the client mount) I ran getfattr -m . -d -e hex <brick>/<file> across all servers in the cluster and 'trusted.ec.dirty' attr is non-zero on all files which don't heal. Is it normal? Any way to correct it? It's my

On Thu, Nov 2, 2017 at 4:00 PM, Amudhan P <amudhan83 at gmail.com> wrote: > if doing an upgrade from 3.10.1 to 4.0 or 4.1, will I be able to access > volume without any challenge? > > I am asking this because 4.0 comes with DHT2? Very short answer, yes. Your volumes will remain the same. And you will continue to access them the same way. RIO (as DHT2 is now known as) developers