Re: [Gluster-devel] [Gluster-users] Glusterfs meta data space consumption issue

2017-04-12 Thread Pranith Kumar Karampuri
Yes On Thu, Apr 13, 2017 at 8:21 AM, ABHISHEK PALIWAL wrote: > Means the fs where this brick has been created? > On Apr 13, 2017 8:19 AM, "Pranith Kumar Karampuri" > wrote: > >> Is your backend filesystem ext4? >> >> On Thu, Apr 13, 2017 at 6:29

Re: [Gluster-devel] [Gluster-users] Glusterfs meta data space consumption issue

2017-04-12 Thread ABHISHEK PALIWAL
Means the fs where this brick has been created? On Apr 13, 2017 8:19 AM, "Pranith Kumar Karampuri" wrote: > Is your backend filesystem ext4? > > On Thu, Apr 13, 2017 at 6:29 AM, ABHISHEK PALIWAL > wrote: > >> No,we are not using sharding >> On Apr

Re: [Gluster-devel] [Gluster-users] Glusterfs meta data space consumption issue

2017-04-12 Thread Pranith Kumar Karampuri
Is your backend filesystem ext4? On Thu, Apr 13, 2017 at 6:29 AM, ABHISHEK PALIWAL wrote: > No,we are not using sharding > On Apr 12, 2017 7:29 PM, "Alessandro Briosi" wrote: > >> Il 12/04/2017 14:16, ABHISHEK PALIWAL ha scritto: >> >> I have did more

Re: [Gluster-devel] [Gluster-users] Glusterfs meta data space consumption issue

2017-04-12 Thread ABHISHEK PALIWAL
No,we are not using sharding On Apr 12, 2017 7:29 PM, "Alessandro Briosi" wrote: > Il 12/04/2017 14:16, ABHISHEK PALIWAL ha scritto: > > I have did more investigation and find out that brick dir size is > equivalent to gluster mount point but .glusterfs having too much

[Gluster-devel] Coverity covscan for 2017-04-12-e536bea0 (master branch)

2017-04-12 Thread staticanalysis
GlusterFS Coverity covscan results are available from http://download.gluster.org/pub/gluster/glusterfs/static-analysis/master/glusterfs-coverity/2017-04-12-e536bea0 ___ Gluster-devel mailing list Gluster-devel@gluster.org

Re: [Gluster-devel] [Gluster-users] Glusterfs meta data space consumption issue

2017-04-12 Thread ABHISHEK PALIWAL
I have did more investigation and find out that brick dir size is equivalent to gluster mount point but .glusterfs having too much difference opt/lvmdir/c2/brick # du -sch * 96K RNC_Exceptions 36K configuration 63Mjava 176K

Re: [Gluster-devel] stat() returns invalid file size when self healing

2017-04-12 Thread Ravishankar N
On 04/12/2017 01:57 PM, Mateusz Slupny wrote: Hi, I'm observing strange behavior when accessing glusterfs 3.10.0 volume through FUSE mount: when self-healing, stat() on a file that I know has non-zero size and is being appended to results in stat() return code 0, and st_size being set to 0

[Gluster-devel] stat() returns invalid file size when self healing

2017-04-12 Thread Mateusz Slupny
Hi, I'm observing strange behavior when accessing glusterfs 3.10.0 volume through FUSE mount: when self-healing, stat() on a file that I know has non-zero size and is being appended to results in stat() return code 0, and st_size being set to 0 as well. Next week I'm planning to find a

Re: [Gluster-devel] bug-1421590-brick-mux-reuse-ports.t failure

2017-04-12 Thread Amar Tumballi
On Wed, Apr 12, 2017 at 12:07 PM, Atin Mukherjee wrote: > As per http://fstat.rht.gluster.org/weeks/1 the test in $Subject has > failed multiple times and is now blocking most of the patches to pass the > regression. I have a patch https://review.gluster.org/#/c/17033/ to >

[Gluster-devel] bug-1421590-brick-mux-reuse-ports.t failure

2017-04-12 Thread Atin Mukherjee
As per http://fstat.rht.gluster.org/weeks/1 the test in $Subject has failed multiple times and is now blocking most of the patches to pass the regression. I have a patch https://review.gluster.org/#/c/17033/ to remove this test entirely and I have the reason in the commit message. Can this patch