+1 to option (2) which similar to echoing into /proc/sys/vm/drop_caches
-Prashanth Pai
- Original Message -
> From: "Mohammed Rafi K C"
> To: "gluster-users" , "Gluster Devel"
>
> Sent: Tuesday, 26 July, 2016 10:44:15 AM
> Subject: [Gluster-devel] Need a way to display and flush glust
On Mon, Jul 25, 2016 at 11:20 AM, Raghavendra Gowdappa
wrote:
>
>
> - Original Message -
>> From: "Amye Scavarda"
>> To: "Gluster Devel" , "OSAS"
>> Sent: Saturday, July 23, 2016 3:13:20 AM
>> Subject: [Gluster-devel] Open Source Storage Summit
>>
>> This was a little late being announce
On Tue, Jul 26, 2016 at 12:34 AM, Niels de Vos wrote:
> On Mon, Jul 25, 2016 at 04:34:17PM +0530, Avra Sengupta wrote:
> > The crux of the problem is that as of today, brick processes on restart
> try
> > to reuse the old port they were using (assuming that no other process
> will
> > be using it
Hi,
Gluster stack has it's own caching mechanism , mostly on client side.
But there is no concrete method to see how much memory are consuming by
gluster for caching and if needed there is no way to flush the cache memory.
So my first question is, Do we require to implement this two features
for
Hi all!
The GlusterFS-3.6 series has been around for nearly 2 years now. The
first 3.6.0 release happened late October 2014. We've had 9 releases
since then, with latest release 3.6.9 happening in early March 2016.
There hasn't been any activity on the release-3.6 branch since then.
The 3.6 series
> As far as I know, there's no explicit guarantee on the order in which
> fini is called, so we cannot rely on it to do cleanup because ec needs
> that all its underlying xlators be fully functional to finish the cleanup.
What kind of cleanup are we talking about here? We already need to
handle t
On 07/25/2016 02:41 AM, Xavier Hernandez wrote:
Hi Jeff,
On 22/07/16 15:37, Jeff Darcy wrote:
Gah! sorry sorry, I meant to send the mail as SIGTERM. Not SIGKILL.
So xavi
and I were wondering why cleanup_and_exit() is not sending
GF_PARENT_DOWN
event.
OK, then that grinding sound you hear is m
On Mon, Jul 25, 2016 at 04:34:17PM +0530, Avra Sengupta wrote:
> The crux of the problem is that as of today, brick processes on restart try
> to reuse the old port they were using (assuming that no other process will
> be using it, and not consulting pmap_registry_alloc() before using it). With
>
On 07/22/2016 08:44 AM, Soumya Koduri wrote:
Hi,
In certain scenarios (esp.,in highly available environments), the
application may have to fail-over/connect to a different glusterFS
client while the I/O is happening. In such cases until there is a ping
timer expiry and glusterFS server cleans up
- Original Message -
> From: "Amye Scavarda"
> To: "Vijay Bellur"
> Cc: "Kaushal M" , "Jonathan Holloway"
> , "Gluster Devel"
> Sent: Sunday, July 24, 2016 7:53:06 PM
> Subject: Re: [Gluster-devel] Proposing a framework to leverage existing
> Python unit test standards for our testing
On Mon, Jul 25, 2016 at 05:43:30AM +0200, Emmanuel Dreyfus wrote:
> Vijay Bellur wrote:
>
> > Do you have any concrete examples of problems encountered due to the
> > same directory stream being invoked from multiple threads?
>
> I am not sure this scenario can happen, but what we had were dire
On Mon, Jul 25, 2016 at 07:37:55PM +0530, Raghavendra Talur wrote:
> >
> >
> >
> > 1. We do not clear the Verified tag. This means if you want to re-run
> >regressions you have to manually trigger it. If your patch is rebased
> > on top
> >of another patch, you may have to retrigger failing
>
> >
> > On the more ambitious side, I think we could also optimize around the
> idea
> > that some parts of the system aren't even present for some tests. For
> > example, most of our tests don't even use GFAPI and won't be affected by
> a
> > GFAPI-only change. Conversely, GFAPI tests won't be
On Mon, Jul 25, 2016 at 6:08 PM, Jeff Darcy wrote:
> > I have a few proposals to reduce this turn around time:
> >
> > 1. We do not clear the Verified tag. This means if you want to re-run
> >regressions you have to manually trigger it. If your patch is rebased
> on
> >top
> >of anoth
>
>
>
> 1. We do not clear the Verified tag. This means if you want to re-run
>regressions you have to manually trigger it. If your patch is rebased
> on top
>of another patch, you may have to retrigger failing regressions
> manually.
>
Yes, matching the settings for Verified flag to that o
> My vision in this regard is something like this:
> * A patchset gets Verified +1.
> * A meta job is kicked off which determines regression jobs to run.
> If the patch only touches GFAPI, we kick off the GFAPI regression tests. If
> it touches multiple modules, we kick off the tests for these
On Mon, Jul 25, 2016 at 7:12 PM, Atin Mukherjee wrote:
>
>
> On Mon, Jul 25, 2016 at 5:37 PM, Atin Mukherjee
> wrote:
>
>>
>>
>> On Mon, Jul 25, 2016 at 4:34 PM, Avra Sengupta
>> wrote:
>>
>>> The crux of the problem is that as of today, brick processes on restart
>>> try to reuse the old port
On Mon, Jul 25, 2016 at 5:37 PM, Atin Mukherjee wrote:
>
>
> On Mon, Jul 25, 2016 at 4:34 PM, Avra Sengupta
> wrote:
>
>> The crux of the problem is that as of today, brick processes on restart
>> try to reuse the old port they were using (assuming that no other process
>> will be using it, and
Hello folks,
With Emmanuel's help, I've added an extra partition to the NetBSD machines. The
/build and /archives folders are now in a new partition mounted at /data. This
partition has about 23 GB of space. It will reduce instances of NetBSD machines
out of action because of lack of space.
A hug
On Mon, Jul 25, 2016 at 08:38:34AM -0400, Jeff Darcy wrote:
> > I have a few proposals to reduce this turn around time:
> >
> > 1. We do not clear the Verified tag. This means if you want to re-run
> >regressions you have to manually trigger it. If your patch is rebased on
> >top
> >of
> I have a few proposals to reduce this turn around time:
>
> 1. We do not clear the Verified tag. This means if you want to re-run
>regressions you have to manually trigger it. If your patch is rebased on
>top
>of another patch, you may have to retrigger failing regressions manually.
On Mon, Jul 25, 2016 at 4:34 PM, Avra Sengupta wrote:
> The crux of the problem is that as of today, brick processes on restart
> try to reuse the old port they were using (assuming that no other process
> will be using it, and not consulting pmap_registry_alloc() before using
> it). With a recen
On 07/25/2016 07:26 AM, Kaleb S. KEITHLEY wrote:
> On 07/23/2016 10:32 AM, Emmanuel Dreyfus wrote:
>> Pranith Kumar Karampuri wrote:
>>
>>> So should we do readdir() with external locks for everything instead?
>>
>> readdir() with a per-directory lock is safe. However, it may come with a
>> perfor
On 07/23/2016 10:32 AM, Emmanuel Dreyfus wrote:
> Pranith Kumar Karampuri wrote:
>
>> So should we do readdir() with external locks for everything instead?
>
> readdir() with a per-directory lock is safe. However, it may come with a
> performance hit in some scenarios, since two threads cannot r
The crux of the problem is that as of today, brick processes on restart
try to reuse the old port they were using (assuming that no other
process will be using it, and not consulting pmap_registry_alloc()
before using it). With a recent change, pmap_registry_alloc (),
reassigns older ports that
Hello,
I'm looking to reduce the number of times we run regressions. It takes a lot of
time and often times, it's not needed.
We carry over the regression flags on rebase[1] and no code change[2] in Gerrit
settings. However, Verified flag is cleared. When we re-grant the verify, we
run regression
- Original Message -
> From: "jayakrishnan mm"
> To: "Gluster Devel" , gluster-us...@gluster.org
> Sent: Monday, 25 July, 2016 3:27:42 PM
> Subject: [Gluster-devel] Why rdma.so is missing often
>
> Gluster version 3.7.6
> I get "Connection failed. Please check if gluster daemon is operat
Gluster version 3.7.6
I get "Connection failed. Please check if gluster daemon is operational.",
sometimes.
When I check the log file , it says that rdma.so cannot be found.
I did remove all the vol files and restarted the glusterd.
Again when I tried to create volume, the connectio
The failure suggests that the port snapd is trying to bind to is already
in use. But snapd has been modified to use a new port everytime. I am
looking into this.
On 07/25/2016 02:23 PM, Nithya Balachandran wrote:
More failures:
https://build.gluster.org/job/rackspace-regression-2GB-triggered/2
On Mon, Jul 18, 2016 at 4:35 PM, Raghavendra Talur
wrote:
>
>
> On Mon, Jul 18, 2016 at 4:10 PM, Prasanna Kalever
> wrote:
>
>> Hey Team,
>>
>>
>> My understanding is that @transport argumet in
>> glfs_set_volfile_server() is meant for specifying transport used in
>> fetching volfile server,
>>
More failures:
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22452/console
I see these messages in the snapd.log:
[2016-07-22 05:31:52.482282] I
[rpcsvc.c:2199:rpcsvc_set_outstanding_rpc_limit] 0-rpc-service: Configured
rpc.outstanding-rpc-limit with value 64
[2016-07-22 05:31:
31 matches
Mail list logo
