All I know is pump translator is written long back to support
'replace-brick' without data-loss in distributed setup too. But we figured
out pump is not maintainable along the way, and said you can't do a
replace-brick in distributed volume type.
https://github.com/gluster/glusterfs/commit/acdeed0
It was used for testing pump xlator functionality. When replace-brick is
done on a distribute volume, it would lead to pump xlator migrating data to
the destination brick from source. I guess we can delete this test. I don't
think we support pump xlator anymore.
On Fri, Sep 8, 2017 at 10:02 AM, At
Thanks all for the feedback!
On Sat, Sep 2, 2017 at 12:21 AM, John Strunk wrote:
>
>
> On Fri, Sep 1, 2017 at 1:27 AM, Amar Tumballi wrote:
>
>> Disclaimer: This email is long, and did take significant time to write.
>> Do take time and read, review and give feedback, so we can have some
>> met
Pranith,
I see you're the author of the test in $Subj. Now while I was working on a
patch https://review.gluster.org/#/c/18226/ to disallow replace brick
operations on dist only volumes the patch failed the regression on this
test as the test actually uses replace brick on a distribute only volume
- Original Message -
> From: "FNU Raghavendra Manjunath"
> To: "Raghavendra Gowdappa"
> Cc: "Raghavendra G" , "Nithya Balachandran"
> , anoo...@redhat.com,
> "Gluster Devel" , "Raghavendra Bhat"
>
> Sent: Thursday, September 7, 2017 6:44:51 PM
> Subject: Re: [Gluster-devel] Need inpu
On Wed, Sep 6, 2017 at 4:49 PM, Raghavendra G
wrote:
>
>
> On Wed, Sep 6, 2017 at 11:16 AM, Csaba Henk wrote:
>
>> Thanks Du, nice bit of info! It made me wander about the following:
>>
>> - Could it be then the default answer we give to "glusterfs client
>> high memory usage"
>> type of compl
>From snapview client perspective one important thing to note. For building
the context for the entry point (by default ".snaps") a explicit lookup has
to be done on it. The dentry for ".snaps" is not returned when readdir is
done on its parent directory (Not even when ls -a is done). So for buildi
On Thu, Sep 07, 2017 at 04:11:22PM +0530, Milind Changire wrote:
> *Squashed Patches*
> I believe, individual engineers have to own the responsibility of
> maintaining history of all appropriate Change-Ids as part of the commit
> message when multiple patches have been squashed/merged into one comm
On 7 Sep 2017 6:25 pm, "Niels de Vos" wrote:
On Thu, Sep 07, 2017 at 04:41:54PM +0530, Nigel Babu wrote:
> On Thu, Sep 07, 2017 at 12:43:28PM +0200, Niels de Vos wrote:
> >
> > Q: Can patches of a series be merged before all patches in the series
> > have a +2? Initial changes that prepare things
On Thu, Sep 07, 2017 at 04:41:54PM +0530, Nigel Babu wrote:
> On Thu, Sep 07, 2017 at 12:43:28PM +0200, Niels de Vos wrote:
> >
> > Q: Can patches of a series be merged before all patches in the series
> > have a +2? Initial changes that prepare things, or add new (unused) core
> > functionalities
GlusterFS Coverity covscan results are available from
http://download.gluster.org/pub/gluster/glusterfs/static-analysis/master/glusterfs-coverity/2017-09-07-eb2f1ab4
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman
On 09/07/2017 02:20 AM, Nigel Babu wrote:
Hello folks,
A few times, we've merged dependent patches out of order because the Submit
type[1] did not block us from doing so. The last few times we've talked about
this, we didn't actually take a strong decision either way. In yesterday's
maintainers
Le jeudi 07 septembre 2017 à 11:17 +0200, Niels de Vos a écrit :
> On Wed, Sep 06, 2017 at 12:39:42PM +0200, Michael Scherer wrote:
> > Hi,
> >
> > so I have been trying to make the internal freebsd builder usable,
> > sinc
> > eit was freshly installed and not building anything.
> >
> > Over the
On Thu, Sep 07, 2017 at 12:43:28PM +0200, Niels de Vos wrote:
>
> Q: Can patches of a series be merged before all patches in the series
> have a +2? Initial changes that prepare things, or add new (unused) core
> functionalities should be mergable so that follow-up patches can be
> posted against t
On Thu, Sep 07, 2017 at 04:11:22PM +0530, Milind Changire wrote:
> *Squashed Patches*
> I believe, individual engineers have to own the responsibility of
> maintaining history of all appropriate Change-Ids as part of the commit
> message when multiple patches have been squashed/merged into one comm
On Thu, Sep 07, 2017 at 12:06:19PM +0530, Amar Tumballi wrote:
> On Thu, Sep 7, 2017 at 11:50 AM, Nigel Babu wrote:
>
> > Hello folks,
> >
> > A few times, we've merged dependent patches out of order because the Submit
> > type[1] did not block us from doing so. The last few times we've talked
>
On Thu, Sep 07, 2017 at 11:50:21AM +0530, Nigel Babu wrote:
> Hello folks,
>
> A few times, we've merged dependent patches out of order because the Submit
> type[1] did not block us from doing so. The last few times we've talked about
> this, we didn't actually take a strong decision either way. I
*Squashed Patches*
I believe, individual engineers have to own the responsibility of
maintaining history of all appropriate Change-Ids as part of the commit
message when multiple patches have been squashed/merged into one commit.
On Thu, Sep 7, 2017 at 11:50 AM, Nigel Babu wrote:
> Hello folk
On Thu, Sep 07, 2017 at 12:17:32PM +0530, Atin Mukherjee wrote:
> One basic question (rather clarification) here. If indeed a rebase is
> necessary for a patch which was posted some time back and a regression was
> passed at that time, with this change will a (centos) regression job
> re-triggered
On Wed, Sep 06, 2017 at 12:39:42PM +0200, Michael Scherer wrote:
> Hi,
>
> so I have been trying to make the internal freebsd builder usable, sinc
> eit was freshly installed and not building anything.
>
> Over the course of the day, I found a few missing deps, found a ton of
> warnings (I starte
20 matches
Mail list logo
