Re: [Gluster-devel] Crash in dht_fsync()

[Raghavendra Gowdappa]

Fix at:
http://review.gluster.com/10929

- Original Message -
> From: "Raghavendra Gowdappa" 
> To: "Raghavendra Gowdappa" 
> Cc: "Vijay Bellur" , "Gluster Devel" 
> 
> Sent: Wednesday, May 27, 2015 8:46:57 AM
> Subject: Re: [Gluster-devel] Crash in dht_fsync()
> 
> During graph change we migrate all the fds opened on old subvol. In this case
> we are trying to migrate fds opened on virtual ".meta" subtree. This has
> resulted in crash as these inodes and fds have to be handled differently
> than the ones in real volumes.
> 
> - Original Message -
> > From: "Raghavendra Gowdappa" 
> > To: "Raghavendra Gowdappa" 
> > Cc: "Vijay Bellur" , "Gluster Devel"
> > 
> > Sent: Tuesday, May 26, 2015 12:02:46 PM
> > Subject: Re: [Gluster-devel] Crash in dht_fsync()
> > 
> > Is there a way to get coredump?
> > 
> > - Raghavendra Gowdappa  wrote:
> > > Will take a look.
> > > 
> > > - Original Message -
> > > > From: "Vijay Bellur" 
> > > > To: "Gluster Devel" 
> > > > Sent: Monday, May 25, 2015 11:08:46 PM
> > > > Subject: [Gluster-devel] Crash in dht_fsync()
> > > > 
> > > > While running tests/performance/open-behind.t in a loop on mainline, I
> > > > observe the crash at [1]. The backtrace seems to point to dht_fsync().
> > > > Can one of the dht developers please take a look in?
> > > > 
> > > > Thanks,
> > > > Vijay
> > > > 
> > > > [1] http://fpaste.org/225375/
> > > > ___
> > > > Gluster-devel mailing list
> > > > Gluster-devel@gluster.org
> > > > http://www.gluster.org/mailman/listinfo/gluster-devel
> > > > 
> > 
> > 
> 
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Proposal: Using LLVM clang-analyzer in gluster development

[Prasanna Kalever]

Niels de Vos, I wish to get access to you setup :)

We know that Clang is compiler more than analyzer, it support many 
Architectures.
you can have a glance at http://llvm.org/docs/doxygen/html/Triple_8h_source.html

Further Compiling clang from source should not be that difficult in many of the 
distros.

Since our purpose is to use Clang-Analyzer only in development of glusterfs, 
that means
only the distributions that developers use i.e. Fedora, CentOs, RHEL, Ubuntu 
and very few others.

>From above, I hope integrating Scan-build in script like checkpatch.pl or any 
>other will be
a good Idea as Athin proposed.


Thanks & Regards,
Prasanna Kumar K



- Original Message -
From: "Atin Mukherjee" 
To: "Niels de Vos" , "Atin Mukherjee" 

Cc: "Gluster Devel" 
Sent: Wednesday, May 27, 2015 9:58:00 AM
Subject: Re: [Gluster-devel] Proposal: Using LLVM clang-analyzer in gluster 
development



On 05/27/2015 12:24 AM, Niels de Vos wrote:
> On Tue, May 26, 2015 at 11:00:25PM +0530, Atin Mukherjee wrote:
>> On 26 May 2015 17:30, "Prasanna Kalever"  wrote:
>>>
>>> Hi gluster team,
>>>
>>> Proposal:
>>>
>>> Using Clang static analyzer tool for gluster project
>>>
>>>
>>> About Clang:
>>>
>>> From a very high level view, Clang has two features
>>>
>>> 1. Clang as a compiler
>>> 2. Clang as a code analyzer
>>>
>>> The Idea hear is to use second point i.e Clang as code analyzer and still
>> gcc
>>> will be our default compiler.
>>>
>>> The Clang Static Analyzer is a source code analysis tool that finds bugs
>> in C,
>>> C++, and Objective-C programs. Given the exact same code base,
>> clang-analyzer
>>> reported ~70 potential issues. clang is an awesome and free tool.
>>>
>>> The reports from clang-analyzer are in HTML and there's a single file for
>> each
>>> issue and it generates a nice looking source code with embedded comments
>> about
>>> which flow that was followed all the way down to the problem.
>>>
>>>
>>> Why Clang-Analyzer: (Advantages)
>>>
>>>  1. Since its is an open source tool:
>>>
>>>   * Available to all the developers
>>>   * Easy Access, we can run the tool while we compile the code (say $
>> scan-build make)
>>>   * No restrictions on Number of Runs per week/day/hour/min ..
>>>   * Defects are Identified before submitting a patch, thus very less
>> chance of
>>> defect injection into project
>>>
>>>  2. The Html view of clang is very impressive with all the source code
>> including
>>> comments of clang-analyzer, which lead to defect line number directly
>> .
>>>
>>>
>>>
>>> I have attached a sample clang results for geo-replication module run on
>> latest
>>> 3.7+ glusterfs code, please find them above.
>>>
>>>
>>> Thanks for your time.
>> On a relative note, I feel we should try to integrate any of these static
>> analyzer as part of our checkpatch.pl and compare the pre and post report
>> and proceed if the change doesn't introduce any new defects. Thoughts?
> 
> That sounds more like a test we can run in Jenkins. Having this check in
> checkpatch.pl might be difficult because that should be able to run on
> any OS/distribution we support. When we move the test to Jenkins, we can
> run it on the regression test slaves and have them post -1 verified in
> case of issues.
Sounds good to me, be it at local or jenkins, my only intention is to
refrain introducing defects for a new patch.
> 
> Are there tools to do the pre/post result comparing? I have recently
> setup a test environment for Jenkins jobs and am happy to give you (or
> any one else) access to it for testing (sorry, my setup is on the Red
> Hat internal network only).
We need to explore on that part, I am hoping that we should have such
kind of tools available. However if not at worst case can't we compare
them through our own scripts?
> 
> Niels
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
> 

-- 
~Atin
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Spurious regression: Checking on 3 test cases

[Jiffin Tony Thottan]

On 26/05/15 20:44, Niels de Vos wrote:

On Tue, May 26, 2015 at 10:17:05AM -0400, Jiffin Thottan wrote:


- Original Message -
From: "Vijay Bellur" 
To: "Krishnan Parthasarathi" , "Shyam" 

Cc: "Gluster Devel" 
Sent: Friday, 22 May, 2015 9:49:15 AM
Subject: Re: [Gluster-devel] Spurious regression: Checking on 3 test cases

On 05/22/2015 07:13 AM, Krishnan Parthasarathi wrote:

Are the following tests in any spurious regression failure lists? or,
noticed by others?

...

2) ./tests/basic/mount-nfs-auth.t
 Run:
http://build.gluster.org/job/rackspace-regression-2GB-triggered/9406/consoleFull


Right now there is no easy fix for the issue. It may require to
reconstruct entire netgroup/export structures used for this feature.

Indeed, my suspicion is that the current structures for
netgroups/exports and the auth_caching is not completely thread safe.
The structures use a dict for gathering entries, and hash some of the
contents of the entry as a key. This makes it quick to check if the
entry has been cached.

There also is a refresh thread that can read the exports and netgroups
file from disk, and creates entries in the dict for the respective
functionality.

The problem (likely) occurs when this happens:

 Step | NFS-client|  refresh thread
--+---+---
  |   |
  1   | mount request |
  | fetch entry from caching dict |
  |   |
  2   |   | timeout expired
  |   | read file from disk
  |   | create and fill a new dict
  |   | replace dict with new one
  |   |
  3   |   | free old dict and entries
  |   |
  4   | try to use the cache entry|
  | SEGFAULT  |
  |   |

Step 1 and 2 can happen at the same time, but 3 has to come after 1 and
before 4. Step 4 is a very minimal usage of the cache entry, this makes
hitting this problem very rare.

Because the netgroups/exports cache entries are kept in a dict, there is
a lot of type-casting going on. It is not trivial to understand how this
works. My preference would be to modify the structures so that we can do
without the dicts, but that is not straight forward either.

I would like to have a refcount for the entries that are fetched from
the dict. But that means that after type-casting the contents from the
dict, there still is a window where the cache entry can get free'd (or
--refcount'd).

The next best thing to do, is adding a lock on the cache structure
itself. Everywhere the cache is accessed, taking a read-lock would be
needed. Adding an entry to the cache would require a write-lock. Looks
like a decent amount of work, and needs careful checking to not miss any
occurrences. This is currently what I think is the most suitable
approach.


+1 for the detailed explanation.

Testing can probably be done by adding a delay in the mount path. Either
a gdb script or systemtap that delays the execution of the thread that
handles the mount.

Other ideas are very much welcome :)
Niels


___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Logjam

[Emmanuel Dreyfus]

Jeff Darcy  wrote:

> As I'm sure you know, security often involves multiple layers.  At the
> time, the OpenSSL method table we used was still one that would allow
> fallback to SSLv3. 

You refer to using ssl23_client_method()? That function's name is really
bad because it is the only one that allows negociation of the highest
protocol available, as opposed to TLSv1_client_method() which is not
able to use TLSv1.2, for instance.

Hence ssl23_client_method() is indeed the way to go, and you are right
it also allows downgrading down to SSLv2 or SSLv3, which is brings
POODLE vulnerability.

But SSL_OP_NO_SSLv2 and SSL_OP_NO_SSLv3 options for
SSL_CTX_set_options() are there to make sure it does cannot happen. At
least this is how it is fixed in all software I have been looking at.

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
m...@netbsd.org
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Proposal: Using LLVM clang-analyzer in gluster development

[Atin Mukherjee]

On 05/27/2015 12:24 AM, Niels de Vos wrote:
> On Tue, May 26, 2015 at 11:00:25PM +0530, Atin Mukherjee wrote:
>> On 26 May 2015 17:30, "Prasanna Kalever"  wrote:
>>>
>>> Hi gluster team,
>>>
>>> Proposal:
>>>
>>> Using Clang static analyzer tool for gluster project
>>>
>>>
>>> About Clang:
>>>
>>> From a very high level view, Clang has two features
>>>
>>> 1. Clang as a compiler
>>> 2. Clang as a code analyzer
>>>
>>> The Idea hear is to use second point i.e Clang as code analyzer and still
>> gcc
>>> will be our default compiler.
>>>
>>> The Clang Static Analyzer is a source code analysis tool that finds bugs
>> in C,
>>> C++, and Objective-C programs. Given the exact same code base,
>> clang-analyzer
>>> reported ~70 potential issues. clang is an awesome and free tool.
>>>
>>> The reports from clang-analyzer are in HTML and there's a single file for
>> each
>>> issue and it generates a nice looking source code with embedded comments
>> about
>>> which flow that was followed all the way down to the problem.
>>>
>>>
>>> Why Clang-Analyzer: (Advantages)
>>>
>>>  1. Since its is an open source tool:
>>>
>>>   * Available to all the developers
>>>   * Easy Access, we can run the tool while we compile the code (say $
>> scan-build make)
>>>   * No restrictions on Number of Runs per week/day/hour/min ..
>>>   * Defects are Identified before submitting a patch, thus very less
>> chance of
>>> defect injection into project
>>>
>>>  2. The Html view of clang is very impressive with all the source code
>> including
>>> comments of clang-analyzer, which lead to defect line number directly
>> .
>>>
>>>
>>>
>>> I have attached a sample clang results for geo-replication module run on
>> latest
>>> 3.7+ glusterfs code, please find them above.
>>>
>>>
>>> Thanks for your time.
>> On a relative note, I feel we should try to integrate any of these static
>> analyzer as part of our checkpatch.pl and compare the pre and post report
>> and proceed if the change doesn't introduce any new defects. Thoughts?
> 
> That sounds more like a test we can run in Jenkins. Having this check in
> checkpatch.pl might be difficult because that should be able to run on
> any OS/distribution we support. When we move the test to Jenkins, we can
> run it on the regression test slaves and have them post -1 verified in
> case of issues.
Sounds good to me, be it at local or jenkins, my only intention is to
refrain introducing defects for a new patch.
> 
> Are there tools to do the pre/post result comparing? I have recently
> setup a test environment for Jenkins jobs and am happy to give you (or
> any one else) access to it for testing (sorry, my setup is on the Red
> Hat internal network only).
We need to explore on that part, I am hoping that we should have such
kind of tools available. However if not at worst case can't we compare
them through our own scripts?
> 
> Niels
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
> 

-- 
~Atin
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Regression-failure] glusterd status

[Atin Mukherjee]

On 05/27/2015 08:55 AM, Krishnan Parthasarathi wrote:
>> I will encourage to do it before this patch gets into the codebase.
> 
> The duplicate peerinfo object issue is different from the problems
> in the current generation number scheme. I don't see why this patch
> needs to wait. We may need to keep volume-snapshot-clone.t disabled
> until the time the duplicate peerinfo issue is resolved, or understood
> better. Does that make sense?
Running snapshot-clone with out this patch encounters failure (once in
two runs), that's what we observed in the last exercise. I know this
issue has nothing to do with the problem we are addressing with this
patch, however snapshot-clone *will not* fail even if we encounter
duplicate peerinfo object issue if we apply this patch. Hope that
clarifies my point of asking to test snapshot-clone.t before this patch
gets in.
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
> 

-- 
~Atin
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] git fetch is failing

[Ravishankar N]

On 05/27/2015 09:03 AM, Ravishankar N wrote:

Looks like gerrit is down. review.gluster.org is not accessible.



Everything seems to be up and running again.


On 05/27/2015 08:58 AM, Pranith Kumar Karampuri wrote:

hi,
 git fetch on local repo fails with the following error. I asked 
on #gluster-dev, some of the people online now face the same error.


pk1@localhost - ~/workspace/gerrit-repo (cooperative-locking-3.7)
08:54:14 :( ⚡ git fetch
ssh_exchange_identification: Connection closed by remote host
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.


Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel


___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel


___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] git fetch is failing

[Ravishankar N]

Looks like gerrit is down. review.gluster.org is not accessible.

On 05/27/2015 08:58 AM, Pranith Kumar Karampuri wrote:

hi,
 git fetch on local repo fails with the following error. I asked 
on #gluster-dev, some of the people online now face the same error.


pk1@localhost - ~/workspace/gerrit-repo (cooperative-locking-3.7)
08:54:14 :( ⚡ git fetch
ssh_exchange_identification: Connection closed by remote host
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.


Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel


___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] git fetch is failing

[Pranith Kumar Karampuri]

hi,
 git fetch on local repo fails with the following error. I asked on 
#gluster-dev, some of the people online now face the same error.


pk1@localhost - ~/workspace/gerrit-repo (cooperative-locking-3.7)
08:54:14 :( ⚡ git fetch
ssh_exchange_identification: Connection closed by remote host
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.


Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Regression-failure] glusterd status

[Krishnan Parthasarathi]

> I will encourage to do it before this patch gets into the codebase.

The duplicate peerinfo object issue is different from the problems
in the current generation number scheme. I don't see why this patch
needs to wait. We may need to keep volume-snapshot-clone.t disabled
until the time the duplicate peerinfo issue is resolved, or understood
better. Does that make sense?
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Crash in dht_fsync()

[Raghavendra Gowdappa]

During graph change we migrate all the fds opened on old subvol. In this case 
we are trying to migrate fds opened on virtual ".meta" subtree. This has 
resulted in crash as these inodes and fds have to be handled differently than 
the ones in real volumes.

- Original Message -
> From: "Raghavendra Gowdappa" 
> To: "Raghavendra Gowdappa" 
> Cc: "Vijay Bellur" , "Gluster Devel" 
> 
> Sent: Tuesday, May 26, 2015 12:02:46 PM
> Subject: Re: [Gluster-devel] Crash in dht_fsync()
> 
> Is there a way to get coredump?
> 
> - Raghavendra Gowdappa  wrote:
> > Will take a look.
> > 
> > - Original Message -
> > > From: "Vijay Bellur" 
> > > To: "Gluster Devel" 
> > > Sent: Monday, May 25, 2015 11:08:46 PM
> > > Subject: [Gluster-devel] Crash in dht_fsync()
> > > 
> > > While running tests/performance/open-behind.t in a loop on mainline, I
> > > observe the crash at [1]. The backtrace seems to point to dht_fsync().
> > > Can one of the dht developers please take a look in?
> > > 
> > > Thanks,
> > > Vijay
> > > 
> > > [1] http://fpaste.org/225375/
> > > ___
> > > Gluster-devel mailing list
> > > Gluster-devel@gluster.org
> > > http://www.gluster.org/mailman/listinfo/gluster-devel
> > > 
> 
> 
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Logjam

[Jeff Darcy]

> > We already exclude CBC, because of the POODLE attack, and that leaves us
> > with 32 ciphers.  Excluding DH as well leaves us with only four.
> > 
> >   AES256-GCM-SHA384
> >   AES256-SHA256
> >   AES128-GCM-SHA256
> >   AES128-SHA256
> 
> Why are ECDH ciphers missing? That list has no cipher featuring PFS,
> that looks really bad.

I guess my filter was too restrictive.  If we allow ECDH but not DH or ADH,
we're at 20.  That seems like a small set.

> My understanding of POODLE is that CBC ciphers are fine, you just need
> to reject the SSLv3 protocol.

As I'm sure you know, security often involves multiple layers.  At the
time, the OpenSSL method table we used was still one that would allow
fallback to SSLv3.  We hadn't yet decided to preclude that, but it
didn't seem wise to leave such systems vulnerable to POODLE either.
Since that attack is specifically against CBC modes with SSLv3, the
defaults were changed to exclude those modes.  Now that we don't allow
SSLv3 at all, it would probably be safe to change those defaults.  As
it turns out, that doesn't increase the number of available ciphers at
all.  We're still at 20.

> > This doesn't seem particularly hard, or at least it wouldn't be if we
> > didn't have to account for every RHEL version and associated OpenSSL
> > version going back ten years.
> 
> The function calls I proposed are used in Apache and Sendmail without
> any OpenSSLversion ifdef.

That's a nice change from the last couple of times we've tried to change
anything related to OpenSSL.
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Logjam

[Emmanuel Dreyfus]

Jeff Darcy  wrote:

> We already exclude CBC, because of the POODLE attack, and that leaves us
> with 32 ciphers.  Excluding DH as well leaves us with only four.
> 
>   AES256-GCM-SHA384
>   AES256-SHA256
>   AES128-GCM-SHA256
>   AES128-SHA256

Why are ECDH ciphers missing? That list has no cipher featuring PFS,
that looks really bad. 

My understanding of POODLE is that CBC ciphers are fine, you just need
to reject the SSLv3 protocol.

> This doesn't seem particularly hard, or at least it wouldn't be if we
> didn't have to account for every RHEL version and associated OpenSSL
> version going back ten years.

The function calls I proposed are used in Apache and Sendmail without
any OpenSSLversion ifdef.

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
m...@netbsd.org
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Logjam

[Jeff Darcy]

> the logjam attack comes in two part. One is about downgrading
> cipher choice because a TLS setup allows EWPORT ciphers. glusterfs
> can thwart this by setting ssl.cipher-list to something hardened enough
> (ECDH:DH:!TLSv1:!aNULL!eNULL seems nice);

Our default is already based on HIGH, which excludes both *NULL and
EXPORT, so I don't think there's any more to be done here.

> Second part is about using pre-computed DH paramaeters. It can be
> worked around aither by
> - removing DH ciphers, which leads to a lack of diversity we may regret
>   later

We already exclude CBC, because of the POODLE attack, and that leaves us
with 32 ciphers.  Excluding DH as well leaves us with only four.

  AES256-GCM-SHA384
  AES256-SHA256
  AES128-GCM-SHA256
  AES128-SHA256

Really that's only one, with different key lengths.  That is cause for
concern.

> - computing your own DH params using openssl dhparam command. Unfortunately
>   glusterfs cannot use that.
> 
> Adding support for loading a DH parameter file is not very difficult:
>   /* generate: openssl dhparam 2048 > /etc/ssl/dhparam.pem */
>   #define DEFAULT_DHPARAM_PATH DEFAULT_ETC_SSL "/dhparam.pem"
>   /* default: priv->ssl_dhparam = DEFAULT_DHPARAM_PATH; */
>   /* (...) */
> 
>   DH *dhpatams;
>   BIO *bio;
>   if ((bio = BIO_new_file(priv->ssl_dhparam, "r")) != NULL) {
> dhparams = PEM_read_bio_DHparams(bio, NULL, NULL, NULL);
> SSL_CTX_set_tmp_dh(mctx->ssl_ctx, dhparams);
> BIO_free(bio);
>   } else {
> /* display error */
>   }
> 
> I am a bit too busy on other fronts to submit code, but whoever is
> interested Of course there should also be the code for
> setting a transport.socket.ssl-dhparam option so that
> DEFAULT_DHPARAM_PATH does not remain hard-coded.

This doesn't seem particularly hard, or at least it wouldn't be if we
didn't have to account for every RHEL version and associated OpenSSL
version going back ten years.  >:-(  I'll investigate further to see
what's the right thing to do.
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Proposal: Using LLVM clang-analyzer in gluster development

[Niels de Vos]

On Tue, May 26, 2015 at 11:00:25PM +0530, Atin Mukherjee wrote:
> On 26 May 2015 17:30, "Prasanna Kalever"  wrote:
> >
> > Hi gluster team,
> >
> > Proposal:
> >
> > Using Clang static analyzer tool for gluster project
> >
> >
> > About Clang:
> >
> > From a very high level view, Clang has two features
> >
> > 1. Clang as a compiler
> > 2. Clang as a code analyzer
> >
> > The Idea hear is to use second point i.e Clang as code analyzer and still
> gcc
> > will be our default compiler.
> >
> > The Clang Static Analyzer is a source code analysis tool that finds bugs
> in C,
> > C++, and Objective-C programs. Given the exact same code base,
> clang-analyzer
> > reported ~70 potential issues. clang is an awesome and free tool.
> >
> > The reports from clang-analyzer are in HTML and there's a single file for
> each
> > issue and it generates a nice looking source code with embedded comments
> about
> > which flow that was followed all the way down to the problem.
> >
> >
> > Why Clang-Analyzer: (Advantages)
> >
> >  1. Since its is an open source tool:
> >
> >   * Available to all the developers
> >   * Easy Access, we can run the tool while we compile the code (say $
> scan-build make)
> >   * No restrictions on Number of Runs per week/day/hour/min ..
> >   * Defects are Identified before submitting a patch, thus very less
> chance of
> > defect injection into project
> >
> >  2. The Html view of clang is very impressive with all the source code
> including
> > comments of clang-analyzer, which lead to defect line number directly
> .
> >
> >
> >
> > I have attached a sample clang results for geo-replication module run on
> latest
> > 3.7+ glusterfs code, please find them above.
> >
> >
> > Thanks for your time.
> On a relative note, I feel we should try to integrate any of these static
> analyzer as part of our checkpatch.pl and compare the pre and post report
> and proceed if the change doesn't introduce any new defects. Thoughts?

That sounds more like a test we can run in Jenkins. Having this check in
checkpatch.pl might be difficult because that should be able to run on
any OS/distribution we support. When we move the test to Jenkins, we can
run it on the regression test slaves and have them post -1 verified in
case of issues.

Are there tools to do the pre/post result comparing? I have recently
setup a test environment for Jenkins jobs and am happy to give you (or
any one else) access to it for testing (sorry, my setup is on the Red
Hat internal network only).

Niels
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Proposal: Using LLVM clang-analyzer in gluster development

[Atin Mukherjee]

On 26 May 2015 17:30, "Prasanna Kalever"  wrote:
>
> Hi gluster team,
>
> Proposal:
>
> Using Clang static analyzer tool for gluster project
>
>
> About Clang:
>
> From a very high level view, Clang has two features
>
> 1. Clang as a compiler
> 2. Clang as a code analyzer
>
> The Idea hear is to use second point i.e Clang as code analyzer and still
gcc
> will be our default compiler.
>
> The Clang Static Analyzer is a source code analysis tool that finds bugs
in C,
> C++, and Objective-C programs. Given the exact same code base,
clang-analyzer
> reported ~70 potential issues. clang is an awesome and free tool.
>
> The reports from clang-analyzer are in HTML and there's a single file for
each
> issue and it generates a nice looking source code with embedded comments
about
> which flow that was followed all the way down to the problem.
>
>
> Why Clang-Analyzer: (Advantages)
>
>  1. Since its is an open source tool:
>
>   * Available to all the developers
>   * Easy Access, we can run the tool while we compile the code (say $
scan-build make)
>   * No restrictions on Number of Runs per week/day/hour/min ..
>   * Defects are Identified before submitting a patch, thus very less
chance of
> defect injection into project
>
>  2. The Html view of clang is very impressive with all the source code
including
> comments of clang-analyzer, which lead to defect line number directly
.
>
>
>
> I have attached a sample clang results for geo-replication module run on
latest
> 3.7+ glusterfs code, please find them above.
>
>
> Thanks for your time.
On a relative note, I feel we should try to integrate any of these static
analyzer as part of our checkpatch.pl and compare the pre and post report
and proceed if the change doesn't introduce any new defects. Thoughts?
>
>
> Best Regards,
> Prasanna Kumar K.
>
>
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
>
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Proposal: Using LLVM clang-analyzer in gluster development

[Ira Cooper]

Prasanna, have you compared the results to the ones we see via coverity?

-Ira

- Original Message -
> Hi gluster team,
> 
> Proposal:
> 
> Using Clang static analyzer tool for gluster project
> 
> 
> 
> About Clang:
> 
> From a very high level view, Clang has two features
> 
> 1. Clang as a compiler
> 2. Clang as a code analyzer
> 
> The Idea hear is to use second point i.e Clang as code analyzer and still gcc
> will be our default compiler.
> 
> The Clang Static Analyzer is a source code analysis tool that finds bugs in
> C,
> C++, and Objective-C programs. Given the exact same code base, clang-analyzer
> reported ~70 potential issues. clang is an awesome and free tool.
> 
> The reports from clang-analyzer are in HTML and there’s a single file for
> each
> issue and it generates a nice looking source code with embedded comments
> about
> which flow that was followed all the way down to the problem.
> 
> 
> 
> Why Clang-Analyzer: (Advantages)
> 
> Since its is an open source tool:
>
>Available to all the developers
>
>Easy Access, we can run the tool while we compile the code (say $
>scan-build make )
>
>No restrictions on Number of Runs per week/day/hour/min ..
>
>Defects are Identified before submitting a patch, thus very less
>chance
>of defect injection into project
> 
> 
> The Html view of clang is very impressive with all the source code including
> comments of clang-analyzer, which lead to defect line number directly .
> 
> I have attached a sample clang results for geo-replication module run on
> latest 3.7+ glusterfs code, please find them above.
> 
> Thanks for your time.
> 
> Best Regards,
> Prasanna Kumar K.
> 
> 
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
> 
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] tests/bugs/fuse/bug-924726.t spurious failure

[Pranith Kumar Karampuri]

hi,
 tests/bugs/fuse/bug-924726.t failed in 
http://build.gluster.org/job/rackspace-regression-2GB-triggered/9553/consoleFull


Could you take a look.

Pranith

___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Spurious regression: Checking on 3 test cases

[Justin Clift]

On 26 May 2015, at 16:14, Niels de Vos  wrote:
> On Tue, May 26, 2015 at 10:17:05AM -0400, Jiffin Thottan wrote:

> Testing can probably be done by adding a delay in the mount path. Either
> a gdb script or systemtap that delays the execution of the thread that
> handles the mount.

Sounds like this is a real problem, that could happen in production
systems (even if rarely).  If that's the case, maybe add it to the test
skipping code in run-tests.sh for now, and re-enable it when the Real
Fix is found? (for 3.7.1/2?)

+ Justin

--
GlusterFS - http://www.gluster.org

An open source, distributed file system scaling to several
petabytes, and handling thousands of clients.

My personal twitter: twitter.com/realjustinclift

___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Backporting spurious failure fixes to release-3.7 branch

[Krutika Dhananjay]

Hi, 

Niels has filed the following bug as tracker for all the spurious tests that 
need a backport from the master branch 
to release-3.7: https://bugzilla.redhat.com:443/show_bug.cgi?id=1225077 

If your fix needs to be backported to release-3.7, please use 1225077 as the 
bug id against your patch. 

Thanks, 
Krutika 
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Cross-layer optimization in GlusterFS

[Toms Varghese]

Hi Everyone,

I am trying to look in to the aspect of optimizing GlusterFS with respect
to the underlying file system (mainly EXT4). Could you please let me know
whether any such cross-layer (between GlusterFS and underlying FS)
optimizations have been already done in GlusterFS?

Regards
Toms Varghese
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Regarding the issues gluster DHT and Layouts of bricks

[Subrata Ghosh]

Sorry for the wrong incomplete message sent by mistake earlier.

Hi Sussant,

Extremely sorry for the belated reply. Thanks  for your input. We will try 
having rebalance then create a set of small files with a random pattern 
generation and check where it falls in by DM_TYPE  DHT.

I have one short query:
We were also thinking to use (in case we need ) Translators/cluster/unify along 
with NUFA or ALU scheduler. However we noticed Translators/cluster/unify became 
 obsolete/legacy in gluster site , does it mean automatically ALU, NUFA,rr 
scheduler also became obsolete or not supported ? Can you please clarify ?

Is the Translators/cluster/unify is supported in 3.3.2 ( we are currently 
using) and following configuration would work ?

If not can you please suggest you how to use ALU/NUFA scheduler with 3.3.2 if 
there is any specific mechanism?

volume unify
   type cluster/unify
   subvolumes brick1 brick2 brick3 brick4
   option namespace brick-ns # should be a node which is not present in 
'subvolumes'
   option scheduler NUFA/ALU/rr# NUFA/ALU or Simple round-robin scheduler
end-volume

Thanks again for your time and advice.

Regards,

-Original Message-
From: Susant Palai [mailto:spa...@redhat.com]
Sent: Thursday, May 21, 2015 6:17 PM
To: Subrata Ghosh
Cc: gluster-devel@gluster.org; gluster-us...@gluster.org; Nobin Mathew; Vijay 
Bellur
Subject: Re: Regarding the issues gluster DHT and Layouts of bricks

Commets inline.

- Original Message -
> From: "Subrata Ghosh" 
> mailto:subrata.gh...@ericsson.com>>
> To: gluster-devel@gluster.org, 
> gluster-us...@gluster.org
> Cc: "Nobin Mathew" 
> mailto:nobin.mat...@ericsson.com>>, "Susant Palai" 
> mailto:spa...@redhat.com>>, "Vijay Bellur"
> mailto:vbel...@redhat.com>>
> Sent: Thursday, 21 May, 2015 4:26:05 PM
> Subject: Regarding the issues gluster DHT and  Layouts of bricks
>
>
> Hi  All,
>
> Could you please guide us  to solve the following DHT and brick layout
> problem we are  dealing with ? Questions are marked bold.
>
> Problem statement :
>
>
> 1.  We have a requirement to achieve maximum write and read performance
> and we have to meet some committed performance metrics.
>
>Our goal is to place each file into different bricks to get
>optimal performance and also observer the nature of the
>throughput , hence need to have a mechanism  to generate
>different hash using gluster glusterfs.gf_dm_hashfn,
> (assuming number of files are : N , Number of Bricks :N)  to place
> spate bricks.
>
>
> -How to make sure each file has different hash and   falls to
> different bricks ?
>
>
>
> -Other way to put the question if I  know the range of the brick
> layout or more precisely if I know the  hex value of the desired hash
> ( so that it will be placed desired brick)  that we need to generate
> from Davis-Meyer algorithm used in gluster,  Can we create a file name
> such that, that also solve our problem to some extent?
>
>
> 2.  We tried to experiment to see  how a file in gluster is decided to be
> placed in a particular brick following gluster glusterfs.gf_dm_hashfn
> and took some idea from
>some articles  like
>http://gluster.readthedocs.org/en/latest/Features/dht/ ,
>https://joejulian.name/blog/dht-misses-are-expensive/ page which
>describes layout for that brick  and calculate a hash for the file.
>
>
> To minimize collisions or generating different hash in such way to
> place each file in different bricks ( file 1 => brick A, file 2 =>
> Brick B, file 3=>  Brick C, file 4 => brick D)
>
>We use kind of similar script to get the hash value for
> a file
>
> def gf_dm_hashfn(filename):
> return ctypes.c_uint32(glusterfs.gf_dm_hashfn(
> filename,
> len(filendame)))
>
> if __name__ == "__main__":
> print hex(gf_dm_hashfn(sys.argv[1]).value)
>
> We can then calculate the hash for a filename:
> # python gf_dm_hash.py file1
> 0x99d1b6fL
>
>
> Extended attribute is fetch to check the range and try to match the
> above generated hash value.
>
> getfattr -n trusted.glusterfs.dht -e hex file1
>
>
>   However we are not able to exactly follow till this point ,  how the
>   hash value matched to one of the layout assignments, to yield what we
>   call a hashed location.
>
>
> -My question is if I  know the range of brick lay out ( say
> 0xc000 to  0x, is range  select a hash 0xc007 ) where
> to be placed the next file can we generate the name ( kind of reverse
> of  gluster
> glusterfs.gf_dm_hashfn) ?

I am not aware of any such mechanism.  You will have to generate file names 
manually and run them through your script to check whether it falls in the 
brick range.

>
> PS :  Susant : Can you throw some light or suggest  a method we are
> trying to solve.
>
> Thanks

Re: [Gluster-devel] Regarding the issues gluster DHT and Layouts of bricks

[Subrata Ghosh]

Hi Sussant,

Extremely sorry for the belated reply. Thanks  for your input. We will try 
having rebalance then create a set of small files with a random pattern 
generation and check where it falls in by DM_TYPE  DHT.

I have one short query:
We were also thinking to use (in case we need ) Translators/cluster/unify. 
Along with NUFA or ALU scheduler. However we noticed Translators/cluster/unify 
is became  obsolete/legacy , in that case automatically ALU, NUFA,rr scheduler 
also became obsolete ?

Is the Translators/cluster/unify




From: Subrata Ghosh
Sent: Thursday, May 21, 2015 4:26 PM
To: gluster-devel@gluster.org; 'gluster-us...@gluster.org'
Cc: Nobin Mathew; 'Susant Palai'; 'Vijay Bellur'
Subject: Regarding the issues gluster DHT and Layouts of bricks


Hi  All,

Could you please guide us  to solve the following DHT and brick layout problem 
we are  dealing with ? Questions are marked bold.

Problem statement :


1.  We have a requirement to achieve maximum write and read performance and 
we have to meet some committed performance metrics.

   Our goal is to place each file into different bricks to get 
optimal performance and also observer the nature of the  throughput , hence 
need to have a mechanism  to generate different hash using gluster 
glusterfs.gf_dm_hashfn,
(assuming number of files are : N , Number of Bricks :N)  to place spate bricks.


-How to make sure each file has different hash and   falls to different 
bricks ?



-Other way to put the question if I  know the range of the brick layout 
or more precisely if I know the  hex value of the desired hash ( so that it 
will be placed desired brick)  that we need to generate from Davis-Meyer 
algorithm used in gluster,  Can we create a file name such that, that also 
solve our problem to some extent?


2.  We tried to experiment to see  how a file in gluster is decided to be 
placed in a particular brick following gluster glusterfs.gf_dm_hashfn and took 
some idea from
   some articles  like 
http://gluster.readthedocs.org/en/latest/Features/dht/ ,  
https://joejulian.name/blog/dht-misses-are-expensive/ page which describes 
layout for that brick  and calculate a hash for the file.


To minimize collisions or generating different hash in such way to 
place each file in different bricks ( file 1 => brick A, file 2 => Brick B, 
file 3=>  Brick C, file 4 => brick D)

   We use kind of similar script to get the hash value for a file

def gf_dm_hashfn(filename):
return ctypes.c_uint32(glusterfs.gf_dm_hashfn(
filename,
len(filendame)))

if __name__ == "__main__":
print hex(gf_dm_hashfn(sys.argv[1]).value)

We can then calculate the hash for a filename:
# python gf_dm_hash.py file1
0x99d1b6fL


Extended attribute is fetch to check the range and try to match the above 
generated hash value.

getfattr -n trusted.glusterfs.dht -e hex file1


  However we are not able to exactly follow till this point ,  how the hash 
value matched to one of the layout assignments, to yield what we call a hashed 
location.


- My question is if I  know the range of brick lay out ( say  
0xc000 to  0x, is range  select a hash 0xc007 ) where to be 
placed the next file can we generate the name ( kind of reverse of  gluster 
glusterfs.gf_dm_hashfn) ?

PS :  Susant : Can you throw some light or suggest  a method we are trying to 
solve.

Thanks for your time.


Best Regards,
Subrata Ghosh






___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Regarding the issues gluster DHT and Layouts of bricks

[Subrata Ghosh]

Hi  All,

Could you please guide us  to solve the following DHT and brick layout problem 
we are  dealing with ? Questions are marked bold.

Problem statement :


1.  We have a requirement to achieve maximum write and read performance and 
we have to meet some committed performance metrics.

   Our goal is to place each file into different bricks to get 
optimal performance and also observer the nature of the  throughput , hence 
need to have a mechanism  to generate different hash using gluster 
glusterfs.gf_dm_hashfn,
(assuming number of files are : N , Number of Bricks :N)  to place spate bricks.


-How to make sure each file has different hash and   falls to different 
bricks ?



-Other way to put the question if I  know the range of the brick layout 
or more precisely if I know the  hex value of the desired hash ( so that it 
will be placed desired brick)  that we need to generate from Davis-Meyer 
algorithm used in gluster,  Can we create a file name such that, that also 
solve our problem to some extent?


2.  We tried to experiment to see  how a file in gluster is decided to be 
placed in a particular brick following gluster glusterfs.gf_dm_hashfn and took 
some idea from
   some articles  like 
http://gluster.readthedocs.org/en/latest/Features/dht/ ,  
https://joejulian.name/blog/dht-misses-are-expensive/ page which describes 
layout for that brick  and calculate a hash for the file.


To minimize collisions or generating different hash in such way to 
place each file in different bricks ( file 1 => brick A, file 2 => Brick B, 
file 3=>  Brick C, file 4 => brick D)

   We use kind of similar script to get the hash value for a file

def gf_dm_hashfn(filename):
return ctypes.c_uint32(glusterfs.gf_dm_hashfn(
filename,
len(filendame)))

if __name__ == "__main__":
print hex(gf_dm_hashfn(sys.argv[1]).value)

We can then calculate the hash for a filename:
# python gf_dm_hash.py file1
0x99d1b6fL


Extended attribute is fetch to check the range and try to match the above 
generated hash value.

getfattr -n trusted.glusterfs.dht -e hex file1


  However we are not able to exactly follow till this point ,  how the hash 
value matched to one of the layout assignments, to yield what we call a hashed 
location.


-My question is if I  know the range of brick lay out ( say  0xc000 
to  0x, is range  select a hash 0xc007 ) where to be placed the 
next file can we generate the name ( kind of reverse of  gluster 
glusterfs.gf_dm_hashfn) ?

PS :  Susant : Can you throw some light or suggest  a method we are trying to 
solve.

Thanks for your time.


Best Regards,
Subrata Ghosh






___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Proposal: Using LLVM clang-analyzer in gluster development

[Prasanna Kalever]

Hi gluster team, 

Proposal:

Using Clang static analyzer tool for gluster project



About Clang:

>From a very high level view, Clang has two features

1. Clang as a compiler
2. Clang as a code analyzer

The Idea hear is to use second point i.e Clang as code analyzer and still gcc
will be our default compiler.

The Clang Static Analyzer is a source code analysis tool that finds bugs in C,
C++, and Objective-C programs. Given the exact same code base, clang-analyzer
reported ~70 potential issues. clang is an awesome and free tool.

The reports from clang-analyzer are in HTML and there’s a single file for each
issue and it generates a nice looking source code with embedded comments about
which flow that was followed all the way down to the problem.



Why Clang-Analyzer: (Advantages)

Since its is an open source tool:
   
   Available to all the developers
   
   Easy Access, we can run the tool while we compile the code (say $ 
scan-build make )
   
   No restrictions on Number of Runs per week/day/hour/min ..
   
   Defects are Identified before submitting a patch, thus very less chance
   of defect injection into project


The Html view of clang is very impressive with all the source code including
comments of clang-analyzer, which lead to defect line number directly .

I have attached a sample clang results for geo-replication module run on latest 
3.7+ glusterfs code, please find them above.

Thanks for your time.

Best Regards, 
Prasanna Kumar K. 



scan-build-geo-repln.tar.bz2
Description: application/bzip-compressed-tar
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Spurious regression: Checking on 3 test cases

[Niels de Vos]

On Tue, May 26, 2015 at 10:17:05AM -0400, Jiffin Thottan wrote:
> 
> 
> - Original Message -
> From: "Vijay Bellur" 
> To: "Krishnan Parthasarathi" , "Shyam" 
> 
> Cc: "Gluster Devel" 
> Sent: Friday, 22 May, 2015 9:49:15 AM
> Subject: Re: [Gluster-devel] Spurious regression: Checking on 3 test cases
> 
> On 05/22/2015 07:13 AM, Krishnan Parthasarathi wrote:
> >
> >> Are the following tests in any spurious regression failure lists? or,
> >> noticed by others?
...
> >> 2) ./tests/basic/mount-nfs-auth.t
> >> Run:
> >> http://build.gluster.org/job/rackspace-regression-2GB-triggered/9406/consoleFull
> >>
> 
> Right now there is no easy fix for the issue. It may require to
> reconstruct entire netgroup/export structures used for this feature.

Indeed, my suspicion is that the current structures for
netgroups/exports and the auth_caching is not completely thread safe.
The structures use a dict for gathering entries, and hash some of the
contents of the entry as a key. This makes it quick to check if the
entry has been cached.

There also is a refresh thread that can read the exports and netgroups
file from disk, and creates entries in the dict for the respective
functionality.

The problem (likely) occurs when this happens:

Step | NFS-client|  refresh thread
   --+---+---
 |   |
 1   | mount request |
 | fetch entry from caching dict |
 |   |
 2   |   | timeout expired
 |   | read file from disk
 |   | create and fill a new dict
 |   | replace dict with new one
 |   |
 3   |   | free old dict and entries
 |   |
 4   | try to use the cache entry|
 | SEGFAULT  |
 |   |

Step 1 and 2 can happen at the same time, but 3 has to come after 1 and
before 4. Step 4 is a very minimal usage of the cache entry, this makes
hitting this problem very rare.

Because the netgroups/exports cache entries are kept in a dict, there is
a lot of type-casting going on. It is not trivial to understand how this
works. My preference would be to modify the structures so that we can do
without the dicts, but that is not straight forward either.

I would like to have a refcount for the entries that are fetched from
the dict. But that means that after type-casting the contents from the
dict, there still is a window where the cache entry can get free'd (or
--refcount'd).

The next best thing to do, is adding a lock on the cache structure
itself. Everywhere the cache is accessed, taking a read-lock would be
needed. Adding an entry to the cache would require a write-lock. Looks
like a decent amount of work, and needs careful checking to not miss any
occurrences. This is currently what I think is the most suitable
approach.

Testing can probably be done by adding a delay in the mount path. Either
a gdb script or systemtap that delays the execution of the thread that
handles the mount.

Other ideas are very much welcome :)
Niels
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Spurious regression: Checking on 3 test cases

[Jiffin Thottan]

- Original Message -
From: "Vijay Bellur" 
To: "Krishnan Parthasarathi" , "Shyam" 

Cc: "Gluster Devel" 
Sent: Friday, 22 May, 2015 9:49:15 AM
Subject: Re: [Gluster-devel] Spurious regression: Checking on 3 test cases

On 05/22/2015 07:13 AM, Krishnan Parthasarathi wrote:
>
>> Are the following tests in any spurious regression failure lists? or,
>> noticed by others?
>>
>> 1) ./tests/basic/ec/ec-5-1.t
>> Run:
>> http://build.gluster.org/job/rackspace-regression-2GB-triggered/9363/consoleFull
>>
>> 2) ./tests/basic/mount-nfs-auth.t
>> Run:
>> http://build.gluster.org/job/rackspace-regression-2GB-triggered/9406/consoleFull
>>

Right now there is no easy fix for the issue. It may require to reconstruct 
entire netgroup/export structures
used for this feature.

>> NOTE: This is a regression run for the same patch as in (1) above, and
>> ec-5-1.t passed in this instance.
>>
>> 3) ./tests/performance/open-behind.t
>> Run:
>> http://build.gluster.org/job/rackspace-regression-2GB-triggered/9407/consoleFull
>

I remember seeing this test fail a few days back but seem to have missed 
including this test in the etherpad.

> None of the above tests are being tracked at 
> https://public.pad.fsfe.org/p/gluster-spurious-failures.
> Should we add them to the list?

Yes and we should add them to is_bad_test() in run-tests.sh too.

Thanks,
Vijay

___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Regression-failure] glusterd status

[Atin Mukherjee]

On 26 May 2015 18:35, "Avra Sengupta"  wrote:
>
> Hi,
>
> What you are refering with the glusterd being restarted might be true,
but I don't remember if the two different peer addresses were before and
after restarting glusterd, or after restarting glusterd and before/after
peer status. We might need to re-do this exercise on a rackspace vm to get
more clarity.
I will encourage to do it before this patch gets into the codebase.
>
> Regards,
> Avra
>
>
> On 05/26/2015 06:26 PM, Kaushal M wrote:
>>
>> These are my findings regarding the issue KP mentioned with
>> volume-snapshot-clone.t.
>>
>>  From what I gathered, the double peerinfo objects issue was observed
>> only via logs. Additional logging was added to
>> glusterd_peer_rpc_notify to log the objects address and
>> peerinfo->hostname . I did the same and observed the same in my logs.
>> But what I found was that glusterd was being restarted in between the
>> logs with different address. So the peerinfo objects were bound to
>> have different addresses.
>>
>> Avra, can you confirm if the above is correct? In the case it is, then
>> I can help debug the issue being faced.
>>
>> I've been running the test on a local vm but, I've not gotten it to
>> fail, even without Avra's partial fix. I spoke to Atin regarding this,
>> and he informed me that the failures are only hit on the rackspace
>> slave VMs. I'll try get access to a slave VM and check the issue out.
>>
>> ~kaushal
>>
>> On Tue, May 26, 2015 at 3:37 PM, Krishnan Parthasarathi
>>  wrote:
>>>
>>> All,
>>>
>>> The following are the regression test failures that are being looked
>>> at by Atin, Avra, Kaushal and self.
>>>
>>> 1) ./tests/bugs/glusterd/bug-974007.t   to be fixed by
http://review.gluster.org/10872
>>>
>>> 2) ./tests/basic/volume-snapshot-clone. to be fixed (partially) by
http://review.gluster.org/10895
>>> There is another issue ('other' part) where there are 2 peerinfo
objects for a given peer/node. This
>>> is being investigated by Kaushal.
>>>
>>> Will keep this thread updated as and when more progress is made.
>>>
>>> cheers,
>>> KP
>>> ___
>>> Gluster-devel mailing list
>>> Gluster-devel@gluster.org
>>> http://www.gluster.org/mailman/listinfo/gluster-devel
>
>
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Removed ./tests/basic/afr/read-subvol-entry.t from is_bad_test()

[Vijay Bellur]

On 05/26/2015 03:44 PM, Ravishankar N wrote:

I have $subject @ http://review.gluster.org/#/c/10917/ because we have
only one known failure for this test @
http://build.gluster.org/job/rackspace-regression-2GB-triggered/8735/consoleFull
and the tests that failed are `gluster volume stop` and `gluster volume
delete`. Not able to repro the issue and the logs don't seem to indicate
anything significant. Hence $subject.



Thanks, Ravi. Merged the patch since both Linux and NetBSD regressions 
ran clean with this.


-Vijay

___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] glusterfs+nfs-ganesha+windows2008 issues

[Soumya Koduri]

Hi Louis,

AFAIK, we never tested nfs-ganesha+glusterfs using windows client. May 
be it would be good if you can collect and provide packet trace/cores or 
logs (with nfs-ganesha atleast in NIV_DEBUG level) on the server side 
while you run these tests to debug futher.


Thanks,
Soumya

On 05/25/2015 08:07 PM, christ1...@sina.com wrote:

Hi, everyone!

My name is Louis, and I am a newcomer of glusterfs. In recent, I want to
set up a cluster by using glusterfs, and use the nfs-ganesha as a nfs
server in user space for considering the performance.   it works well
when i  use linux client to

access the volume which create by the glusterfs in the cluster by
mounting the export directory(like that below):

In the cluster, it had export the dir for specified client,like that:

showmount -e ip--->/test-volume  clientip


In the linux client:  mount  -t nfs clusternodeip:/test-volume
  mountpoint> everything goes well !!


But when I use Windows2008 nfs client to mount the export dir, it can be
mounted successfully, but can not write data to the mounted path. It
occurred those errors below:


1¡¢ Sometimes£¬Windows2008 occurred "0x800704C9"

 error
when copy file to the nfs server from the Windows2008 nfs client.


2¡¢Sometimes£¬it will take a long time to start copy datas when copy
file from the Windows2008 to nfs server(nfs-ganesha), and led to the nfs
server(nfs-ganesha) interrupted,  the nfs-ganesha log message like that
below:


ganesha.nfsd[15529]: segfault at c0 ip 004faac7 sp
7f9eb29f3ad0 error 4 in

ganesha.nfsd[40+20a000]


In a word,  when I use mode like that: Windows2008(nfs client) +
nfs-ganesha(nfs server) + glusterfs(volumes), it can not work well !
  There will occur some errors. Did anybody use that mode and goes well
?  Please help me to let this mode goes well. Thanks a lot !


Best regards



Louis

  2015/5/25



___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel


___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Regression-failure] glusterd status

[Avra Sengupta]

Hi,

What you are refering with the glusterd being restarted might be true, 
but I don't remember if the two different peer addresses were before and 
after restarting glusterd, or after restarting glusterd and before/after 
peer status. We might need to re-do this exercise on a rackspace vm to 
get more clarity.


Regards,
Avra

On 05/26/2015 06:26 PM, Kaushal M wrote:

These are my findings regarding the issue KP mentioned with
volume-snapshot-clone.t.

 From what I gathered, the double peerinfo objects issue was observed
only via logs. Additional logging was added to
glusterd_peer_rpc_notify to log the objects address and
peerinfo->hostname . I did the same and observed the same in my logs.
But what I found was that glusterd was being restarted in between the
logs with different address. So the peerinfo objects were bound to
have different addresses.

Avra, can you confirm if the above is correct? In the case it is, then
I can help debug the issue being faced.

I've been running the test on a local vm but, I've not gotten it to
fail, even without Avra's partial fix. I spoke to Atin regarding this,
and he informed me that the failures are only hit on the rackspace
slave VMs. I'll try get access to a slave VM and check the issue out.

~kaushal

On Tue, May 26, 2015 at 3:37 PM, Krishnan Parthasarathi
 wrote:

All,

The following are the regression test failures that are being looked
at by Atin, Avra, Kaushal and self.

1) ./tests/bugs/glusterd/bug-974007.t   to be fixed by  
http://review.gluster.org/10872

2) ./tests/basic/volume-snapshot-clone. to be fixed (partially) by  
http://review.gluster.org/10895
There is another issue ('other' part) where there are 2 peerinfo objects 
for a given peer/node. This
is being investigated by Kaushal.

Will keep this thread updated as and when more progress is made.

cheers,
KP
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel


___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Regression-failure] glusterd status

[Kaushal M]

These are my findings regarding the issue KP mentioned with
volume-snapshot-clone.t.

>From what I gathered, the double peerinfo objects issue was observed
only via logs. Additional logging was added to
glusterd_peer_rpc_notify to log the objects address and
peerinfo->hostname . I did the same and observed the same in my logs.
But what I found was that glusterd was being restarted in between the
logs with different address. So the peerinfo objects were bound to
have different addresses.

Avra, can you confirm if the above is correct? In the case it is, then
I can help debug the issue being faced.

I've been running the test on a local vm but, I've not gotten it to
fail, even without Avra's partial fix. I spoke to Atin regarding this,
and he informed me that the failures are only hit on the rackspace
slave VMs. I'll try get access to a slave VM and check the issue out.

~kaushal

On Tue, May 26, 2015 at 3:37 PM, Krishnan Parthasarathi
 wrote:
> All,
>
> The following are the regression test failures that are being looked
> at by Atin, Avra, Kaushal and self.
>
> 1) ./tests/bugs/glusterd/bug-974007.t   to be fixed by  
> http://review.gluster.org/10872
>
> 2) ./tests/basic/volume-snapshot-clone. to be fixed (partially) by  
> http://review.gluster.org/10895
>There is another issue ('other' part) where there are 2 peerinfo objects 
> for a given peer/node. This
>is being investigated by Kaushal.
>
> Will keep this thread updated as and when more progress is made.
>
> cheers,
> KP
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] REMINDER: Gluster Community Bug Triage meeting today at 12:00 UTC (~in 85 minutes)

[Atin Mukherjee]

On 05/26/2015 04:05 PM, Atin Mukherjee wrote:
> Hi all,
> 
> This meeting is scheduled for anyone that is interested in learning more
> about, or assisting with the Bug Triage.
> 
> Meeting details:
> - location: #gluster-meeting on Freenode IRC
> ( https://webchat.freenode.net/?channels=gluster-meeting )
> - date: every Tuesday
> - time: 12:00 UTC
> (in your terminal, run: date -d "12:00 UTC")
> - agenda: https://public.pad.fsfe.org/p/gluster-bug-triage
> 
> Currently the following items are listed:
> * Roll Call
> * Status of last weeks action items
> * Group Triage
> * Open Floor
> 
> The last two topics have space for additions. If you have a suitable bug
> or topic to discuss, please add it to the agenda.
> 
> Appreciate your participation.
> 
> Niels

Minutes:
http://meetbot.fedoraproject.org/gluster-meeting/2015-05-26/gluster-meeting.2015-05-26-12.00.html
Minutes (text):
http://meetbot.fedoraproject.org/gluster-meeting/2015-05-26/gluster-meeting.2015-05-26-12.00.txt
Log:
http://meetbot.fedoraproject.org/gluster-meeting/2015-05-26/gluster-meeting.2015-05-26-12.00.log.html

Meeting summary

roll call (atinmu, 12:01:14)
https://public.pad.fsfe.org/p/gluster-bug-triage <- agenda for
today (ndevos, 12:03:44)

group triage (atinmu, 12:05:15)
bug triage link to be referred : https://goo.gl/CYpoFn (atinmu,
12:05:35)
http://goo.gl/WuDQun (atinmu, 12:06:57)

Open Floor (atinmu, 12:22:00)



Meeting ended at 12:33:05 UTC (full logs).

Action items

(none)



People present (lines said)

atinmu (33)
ndevos (20)
soumya (4)
zodbot (2)
kkeithley (2)
rjoseph (1)

> 

-- 
~Atin
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Proposal: Using LLVM clang-analyzer in gluster development

[Kaleb S. KEITHLEY]

Hi,

We already are running nightly builds using both clang compile and clang 
analyze.


see http://download.gluster.org/pub/gluster/glusterfs/static-analysis/


On 05/26/2015 08:00 AM, Prasanna Kalever wrote:

Hi gluster team,

Proposal:

Using Clang static analyzer tool for gluster project


About Clang:

 From a very high level view, Clang has two features

1. Clang as a compiler
2. Clang as a code analyzer

The Idea hear is to use second point i.e Clang as code analyzer and still gcc
will be our default compiler.

The Clang Static Analyzer is a source code analysis tool that finds bugs in C,
C++, and Objective-C programs. Given the exact same code base, clang-analyzer
reported ~70 potential issues. clang is an awesome and free tool.

The reports from clang-analyzer are in HTML and there's a single file for each
issue and it generates a nice looking source code with embedded comments about
which flow that was followed all the way down to the problem.


Why Clang-Analyzer: (Advantages)

  1. Since its is an open source tool:

   * Available to all the developers
   * Easy Access, we can run the tool while we compile the code (say $ 
scan-build make)
   * No restrictions on Number of Runs per week/day/hour/min ..
   * Defects are Identified before submitting a patch, thus very less chance of
 defect injection into project

  2. The Html view of clang is very impressive with all the source code 
including
 comments of clang-analyzer, which lead to defect line number directly .



I have attached a sample clang results for geo-replication module run on latest
3.7+ glusterfs code, please find them above.


Thanks for your time.


Best Regards,
Prasanna Kumar K.



___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel



--

Kaleb
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Proposal: Using LLVM clang-analyzer in gluster development

[Prasanna Kalever]

Hi gluster team, 

Proposal:

Using Clang static analyzer tool for gluster project


About Clang:

>From a very high level view, Clang has two features

1. Clang as a compiler
2. Clang as a code analyzer

The Idea hear is to use second point i.e Clang as code analyzer and still gcc
will be our default compiler.

The Clang Static Analyzer is a source code analysis tool that finds bugs in C,
C++, and Objective-C programs. Given the exact same code base, clang-analyzer
reported ~70 potential issues. clang is an awesome and free tool.

The reports from clang-analyzer are in HTML and there's a single file for each
issue and it generates a nice looking source code with embedded comments about
which flow that was followed all the way down to the problem.


Why Clang-Analyzer: (Advantages)

 1. Since its is an open source tool:
   
  * Available to all the developers
  * Easy Access, we can run the tool while we compile the code (say $ 
scan-build make)
  * No restrictions on Number of Runs per week/day/hour/min ..
  * Defects are Identified before submitting a patch, thus very less chance of
defect injection into project

 2. The Html view of clang is very impressive with all the source code including
comments of clang-analyzer, which lead to defect line number directly .



I have attached a sample clang results for geo-replication module run on latest
3.7+ glusterfs code, please find them above.


Thanks for your time.


Best Regards, 
Prasanna Kumar K. 



scan-build-geo-repln.tar.bz2
Description: application/bzip-compressed-tar
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Moratorium on new patch acceptance

[Raghavendra Gowdappa]

Status on crash in dht_fsync reported by Vijay Bellur:

I am not able to reproduce the issue. However I am consistently hitting a 
failure in the last test of ./tests/performance/open-behind.t (test 18). The 
test reads as:


gluster volume top $V0 open | grep -w "$F0" >/dev/null 2>&1
TEST [ $? -eq 0 ];

"gluster volume top" is not giving file name in the output causing grep to fail 
resulting in failure of test.

regards,
Raghavendra.

- Original Message -
> From: "Vijaikumar M" 
> To: "Gluster Devel" 
> Sent: Tuesday, May 26, 2015 4:43:23 PM
> Subject: Re: [Gluster-devel] Moratorium on new patch acceptance
> 
> Here is the status on quota test-case spurious failure:
> 
> There were 3 issues
> 1) Quota exceeding the limit because of parallel writes - Merged
> Upstream, patch submitted to release-3.7 #10910
>  ./tests/bugs/quota/bug-1038598.t
>  ./tests/bugs/distribute/bug-1161156.t
> 2) Quoting accounting going wrong - Patch Submitted #10918
>  ./tests/basic/ec/quota.t
>  ./tests/basic/quota-nfs.t
> 3) Quota with anonymous FDs on NetBSD:
> This is NFS client caching issue on NetBSD. Sachin and Myself are
> working on this issue.
>  ./tests/basic/quota-anon-fd-nfs.t
> 
> 
> Thanks,
> Vijay
> 
> 
> On Friday 22 May 2015 11:45 PM, Vijay Bellur wrote:
> > On 05/21/2015 12:07 AM, Vijay Bellur wrote:
> >> On 05/19/2015 11:56 PM, Vijay Bellur wrote:
> >>> On 05/18/2015 08:03 PM, Vijay Bellur wrote:
>  On 05/16/2015 03:34 PM, Vijay Bellur wrote:
> 
> >
> > I will send daily status updates from Monday (05/18) about this so
> > that
> > we are clear about where we are and what needs to be done to remove
> > this
> > moratorium. Appreciate your help in having a clean set of regression
> > tests going forward!
> >
> 
>  We have made some progress since Saturday. The problem with glupy.t
>  has
>  been fixed - thanks to Niels! All but following tests have developers
>  looking into them:
> 
>   ./tests/basic/afr/entry-self-heal.t
> 
>   ./tests/bugs/replicate/bug-976800.t
> 
>   ./tests/bugs/replicate/bug-1015990.t
> 
>   ./tests/bugs/quota/bug-1038598.t
> 
>   ./tests/basic/ec/quota.t
> 
>   ./tests/basic/quota-nfs.t
> 
>   ./tests/bugs/glusterd/bug-974007.t
> 
>  Can submitters of these test cases or current feature owners pick
>  these
>  up and start looking into the failures please? Do update the spurious
>  failures etherpad [1] once you pick up a particular test.
> 
> 
>  [1] https://public.pad.fsfe.org/p/gluster-spurious-failures
> >>>
> >>>
> >>> Update for today - all tests that are known to fail have owners. Thanks
> >>> everyone for chipping in! I think we should be able to lift this
> >>> moratorium and resume normal patch acceptance shortly.
> >>>
> >>
> >> Today's update - Pranith fixed a bunch of failures in erasure coding and
> >> Avra removed a test that was not relevant anymore - thanks for that!
> >>
> >> Quota, afr, snapshot & tiering tests are being looked into. Will provide
> >> an update on where we are with these tomorrow.
> >>
> >
> > A few tests have not been readily reproducible. Of the remaining
> > tests, all but the following have either been root caused or we have
> > patches in review:
> >
> > ./tests/basic/mount-nfs-auth.t
> > ./tests/performance/open-behind.t
> > ./tests/basic/ec/ec-5-2.t
> > ./tests/basic/quota-nfs.t
> >
> > With some reviews and investigations of failing tests happening over
> > the weekend, I am optimistic about being able to accept patches as
> > usual from early next week.
> >
> > Thanks,
> > Vijay
> >
> > ___
> > Gluster-devel mailing list
> > Gluster-devel@gluster.org
> > http://www.gluster.org/mailman/listinfo/gluster-devel
> 
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
> 
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Moratorium on new patch acceptance

[Vijaikumar M]

Here is the status on quota test-case spurious failure:

There were 3 issues
1) Quota exceeding the limit because of parallel writes - Merged 
Upstream, patch submitted to release-3.7 #10910

./tests/bugs/quota/bug-1038598.t
./tests/bugs/distribute/bug-1161156.t
2) Quoting accounting going wrong - Patch Submitted #10918
./tests/basic/ec/quota.t
./tests/basic/quota-nfs.t
3) Quota with anonymous FDs on NetBSD:
   This is NFS client caching issue on NetBSD. Sachin and Myself are 
working on this issue.

./tests/basic/quota-anon-fd-nfs.t


Thanks,
Vijay


On Friday 22 May 2015 11:45 PM, Vijay Bellur wrote:

On 05/21/2015 12:07 AM, Vijay Bellur wrote:

On 05/19/2015 11:56 PM, Vijay Bellur wrote:

On 05/18/2015 08:03 PM, Vijay Bellur wrote:

On 05/16/2015 03:34 PM, Vijay Bellur wrote:



I will send daily status updates from Monday (05/18) about this so 
that

we are clear about where we are and what needs to be done to remove
this
moratorium. Appreciate your help in having a clean set of regression
tests going forward!



We have made some progress since Saturday. The problem with glupy.t 
has

been fixed - thanks to Niels! All but following tests have developers
looking into them:

 ./tests/basic/afr/entry-self-heal.t

 ./tests/bugs/replicate/bug-976800.t

 ./tests/bugs/replicate/bug-1015990.t

 ./tests/bugs/quota/bug-1038598.t

 ./tests/basic/ec/quota.t

 ./tests/basic/quota-nfs.t

 ./tests/bugs/glusterd/bug-974007.t

Can submitters of these test cases or current feature owners pick 
these

up and start looking into the failures please? Do update the spurious
failures etherpad [1] once you pick up a particular test.


[1] https://public.pad.fsfe.org/p/gluster-spurious-failures



Update for today - all tests that are known to fail have owners. Thanks
everyone for chipping in! I think we should be able to lift this
moratorium and resume normal patch acceptance shortly.



Today's update - Pranith fixed a bunch of failures in erasure coding and
Avra removed a test that was not relevant anymore - thanks for that!

Quota, afr, snapshot & tiering tests are being looked into. Will provide
an update on where we are with these tomorrow.



A few tests have not been readily reproducible. Of the remaining 
tests, all but the following have either been root caused or we have 
patches in review:


./tests/basic/mount-nfs-auth.t
./tests/performance/open-behind.t
./tests/basic/ec/ec-5-2.t
./tests/basic/quota-nfs.t

With some reviews and investigations of failing tests happening over 
the weekend, I am optimistic about being able to accept patches as 
usual from early next week.


Thanks,
Vijay

___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel


___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Spurious failure fix - entry-self-heal.t

[Krutika Dhananjay]

Pranith, 

I sent a patch to fix the spurious failure in entry-self-heal.t @ 
http://review.gluster.org/#/c/10916/ . 
Requesting a review on the same. 

-Krutika 
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] REMINDER: Gluster Community Bug Triage meeting today at 12:00 UTC (~in 85 minutes)

[Atin Mukherjee]

Hi all,

This meeting is scheduled for anyone that is interested in learning more
about, or assisting with the Bug Triage.

Meeting details:
- location: #gluster-meeting on Freenode IRC
( https://webchat.freenode.net/?channels=gluster-meeting )
- date: every Tuesday
- time: 12:00 UTC
(in your terminal, run: date -d "12:00 UTC")
- agenda: https://public.pad.fsfe.org/p/gluster-bug-triage

Currently the following items are listed:
* Roll Call
* Status of last weeks action items
* Group Triage
* Open Floor

The last two topics have space for additions. If you have a suitable bug
or topic to discuss, please add it to the agenda.

Appreciate your participation.

Niels
-- 
~Atin
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Removed ./tests/basic/afr/read-subvol-entry.t from is_bad_test()

[Ravishankar N]

I have $subject @ http://review.gluster.org/#/c/10917/ because we have 
only one known failure for this test @ 
http://build.gluster.org/job/rackspace-regression-2GB-triggered/8735/consoleFull 
and the tests that failed are `gluster volume stop` and `gluster volume 
delete`. Not able to repro the issue and the logs don't seem to indicate 
anything significant. Hence $subject.


-Ravi
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] [Regression-failure] glusterd status

[Krishnan Parthasarathi]

All,

The following are the regression test failures that are being looked
at by Atin, Avra, Kaushal and self.

1) ./tests/bugs/glusterd/bug-974007.t   to be fixed by  
http://review.gluster.org/10872

2) ./tests/basic/volume-snapshot-clone. to be fixed (partially) by  
http://review.gluster.org/10895
   There is another issue ('other' part) where there are 2 peerinfo objects for 
a given peer/node. This
   is being investigated by Kaushal.

Will keep this thread updated as and when more progress is made.

cheers,
KP
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Adding basic/ec/ec.t to is_bad_test due to spurious failures

[Krishnan Parthasarathi]

- Original Message -
> Pranith/Xavi,
> 
> ./tests/basic/ec/ec.t is part of
> https://public.pad.fsfe.org/p/gluster-spurious-failures
> but is not part of is_bad_test() in run-tests.sh. This has repeatedly
> failed an other independent spurious regression failure fix,
> http://review.gluster.com/10872
> (for bugs/glusterd/bug-974007.t). Please merge
> http://review.gluster.org/10907 to
> unblock other regression test failure fixes.

Here is the link to the regression run which failed in basic/ec.t.
http://build.gluster.org/job/rackspace-regression-2GB/1167/consoleFull
Hope that helps in analysis.
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] New spurious failure?

[Atin Mukherjee]

I happen to see tests/bugs/nfs/bug-904065.t failing for one of the test
run [1]
I believe this failure has nothing to do with [2]   

[1]
http://build.gluster.org/job/rackspace-regression-2GB-triggered/9527/consoleFull
[2] http://review.gluster.org/#/c/10820/
-- 
~Atin
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Logjam

[Emmanuel Dreyfus]

Hi

the logjam attack comes in two part. One is about downgrading 
cipher choice because a TLS setup allows EWPORT ciphers. glusterfs 
can thwart this by setting ssl.cipher-list to something hardened enough
(ECDH:DH:!TLSv1:!aNULL!eNULL seems nice);

Second part is about using pre-computed DH paramaeters. It can be
worked around aither by
- removing DH ciphers, which leads to a lack of diversity we may regret
  later
- computing your own DH params using openssl dhparam command. Unfortunately
  glusterfs cannot use that.

Adding support for loading a DH parameter file is not very difficult:
  /* generate: openssl dhparam 2048 > /etc/ssl/dhparam.pem */ 
  #define DEFAULT_DHPARAM_PATH DEFAULT_ETC_SSL "/dhparam.pem"
  /* default: priv->ssl_dhparam = DEFAULT_DHPARAM_PATH; */
  /* (...) */

  DH *dhpatams;
  BIO *bio;
  if ((bio = BIO_new_file(priv->ssl_dhparam, "r")) != NULL) {
dhparams = PEM_read_bio_DHparams(bio, NULL, NULL, NULL);
SSL_CTX_set_tmp_dh(mctx->ssl_ctx, dhparams);
BIO_free(bio);
  } else {
/* display error */
  }

I am a bit too busy on other fronts to submit code, but whoever is
interested Of course there should also be the code for
setting a transport.socket.ssl-dhparam option so that 
DEFAULT_DHPARAM_PATH does not remain hard-coded.

-- 
Emmanuel Dreyfus
m...@netbsd.org
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Crash in dht_fsync()

[Vijay Bellur]

On 05/26/2015 12:02 PM, Raghavendra Gowdappa wrote:

Is there a way to get coredump?



Running the same test in a loop seems to trigger the crash (1 out of 40 
runs approximately).


I will upload the core to a bz but I figure the above will be faster.

Thanks,
Vijay


- Raghavendra Gowdappa  wrote:

Will take a look.

- Original Message -

From: "Vijay Bellur" 
To: "Gluster Devel" 
Sent: Monday, May 25, 2015 11:08:46 PM
Subject: [Gluster-devel] Crash in dht_fsync()

While running tests/performance/open-behind.t in a loop on mainline, I
observe the crash at [1]. The backtrace seems to point to dht_fsync().
Can one of the dht developers please take a look in?

Thanks,
Vijay

[1] http://fpaste.org/225375/
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel







___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel