I add some private function in dht_create() as bellow.
When current pwd is not /,everything is ok,otherwise,syncop_getxattr
will
be blocked(In target subvol,server3_3_getxatt did not run ).
dict_t *xattr = NULL;
loc_t loc = {0, };
memset (loc.gfid, 0, 16);
loc.gfid[15] = 1;
ret =
On 29 Apr 2015, at 08:05, Niels de Vos nde...@redhat.com wrote:
On Wed, Apr 29, 2015 at 02:40:54AM -0400, Jeff Darcy wrote:
label.Label-Name.copyAllScoresOnTrivialRebase
If true, all scores for the label are copied forward when a new patch
set is uploaded that is a trivial rebase. A new
Hi All,
Just pushed tag v3.7.0beta1 to glusterfs.git. A tarball of 3.7.0beta1 is
now available at [1]. RPM and other packages will appear in
download.gluster.org when the respective packages are ready.
Important features available in beta1 include:
- bitrot
- tiering
- inode quotas
-
Reminder!!!
The weekly Gluster Community meeting is in 30 mins, in
#gluster-meeting on IRC.
This is a completely public meeting, everyone is encouraged
to attend and be a part of it. :)
To add Agenda items
***
Just add them to the main text of the Etherpad, and be at
the
We want to place file on any subvol other than local ,in the contrary of
NUFA。
From GDB ,syncop_getxattr is on the same backtrace of
event_dispatch_epoll_handler which runing in main thread.So any response
can not come in ?
That is the short answer.
syncop_* calls need to be executed in a
Hi Ben
I checked out the glusterfs process attaching gdb and I could not find the
newer code. Can you confirm whether you took the new patch ? patch i:
http://review.gluster.org/#/c/9657/
Thanks,
Susant
- Original Message -
From: Susant Palai spa...@redhat.com
To: Benjamin Turner
On Wed, Apr 29, 2015 at 02:40:54AM -0400, Jeff Darcy wrote:
label.Label-Name.copyAllScoresOnTrivialRebase
If true, all scores for the label are copied forward when a new patch
set is uploaded that is a trivial rebase. A new patch set is considered
as trivial rebase if the commit
On 04/29/2015 11:55 AM, Atin Mukherjee wrote:
I've seen few cases where we are using mainline bugs in submitting
patches in 3.7 release. Process wise this looks incorrect to me. IIRC,
earlier the smoke used to complaint about it, but I am not seeing that
either these days. Any recent changes on
On 28 April 2015 at 01:03, Benjamin Turner bennytu...@gmail.com wrote:
Hi Kiran, thanks for the feedback! I already put up a repo on githib:
https://github.com/bennyturns/gluster-bench
On my TODO list is:
-The benchmark is currently RHEL / RHGS(Red Hat Gluster Storage) specific,
I want
label.Label-Name.copyAllScoresOnTrivialRebase
If true, all scores for the label are copied forward when a new patch
set is uploaded that is a trivial rebase. A new patch set is considered
as trivial rebase if the commit message is the same as in the previous
patch set and if it has
I've seen few cases where we are using mainline bugs in submitting
patches in 3.7 release. Process wise this looks incorrect to me. IIRC,
earlier the smoke used to complaint about it, but I am not seeing that
either these days. Any recent changes on this?
IMO, we should clone all the mainline
Hi Ben,
Yes we were using pure dist volume. Will check in to your systems for more
info.
Can you please update which patch set you used ? In the mean time I will do one
set of test with the same configuration on a small data set.
Thanks,
Susant
- Original Message -
From: Benjamin
On 04/29/2015 11:55 AM, Atin Mukherjee wrote:
I've seen few cases where we are using mainline bugs in submitting
patches in 3.7 release. Process wise this looks incorrect to me. IIRC,
earlier the smoke used to complaint about it, but I am not seeing that
either these days. Any recent changes
- Original Message -
From: M S Vishwanath Bhat msvb...@gmail.com
To: Benjamin Turner bennytu...@gmail.com
Cc: Kiran Patil ki...@fractalio.com, gluster-us...@gluster.org, Gluster
Devel gluster-devel@gluster.org,
btur...@redhat.com
Sent: Wednesday, April 29, 2015 3:20:12 AM
Subject:
Doh my mistake, I thought it was merged. I was just running with the
upstream 3.7 daily. Can I use this run as my baseline and then I can run
next time on the patch to show the % improvement? I'll wipe everything and
try on the patch, any idea when it will be merged?
-b
On Wed, Apr 29, 2015
Any reason you don't want to run it as: `glusterd --xlator-option
*.upgrade=on -N /dev/null 21` ?
On 04/29/2015 11:56 AM, Kaushal M wrote:
If we were to run without `-N`, in daemon mode, yum wouldn't know when
glusterd actually finished the upgrade process. Yum would consider the
parent
On Wednesday 29 April 2015 09:26 PM, Kaushal M wrote:
If we were to run without `-N`, in daemon mode, yum wouldn't know when
glusterd actually finished the upgrade process. Yum would consider the
parent process returning to be the end.
I did an experiment and here is what I found,
[root@192
Hi,
As part of the yum upgrade procedure, when glusterfs-server is updated
we run glusterd in no daemon mode along with upgrade option with this
command.
glusterd --xlator-option *.upgrade=on -N
This helps us update our vol files with new defaults along with
few other things.(say we added a
Doh my mistake, I thought it was merged. I was just running with the
upstream 3.7 daily. Can I use this run as my baseline and then I can run
next time on the patch to show the % improvement? I'll wipe everything and
try on the patch, any idea when it will be merged?
Yes, it would be very
On Apr 29, 2015 22:00, Kaleb S. KEITHLEY kkeit...@redhat.com wrote:
Any reason you don't want to run it as: `glusterd --xlator-option
*.upgrade=on -N /dev/null 21` ?
No reason. Just felt it is not really intuitive or explanatory on why someone
should compulsorily use no-daemon option
On Wed, Apr 29, 2015 at 12:30:20PM -0400, Kaleb S. KEITHLEY wrote:
Any reason you don't want to run it as: `glusterd --xlator-option
*.upgrade=on -N /dev/null 21` ?
I think it would be nicer to use --log-level=/dev/null instead, or would
that not override the -N option?
Niels
On
On Wed, Apr 29, 2015 at 09:14:37PM +0200, Niels de Vos wrote:
On Wed, Apr 29, 2015 at 12:30:20PM -0400, Kaleb S. KEITHLEY wrote:
Any reason you don't want to run it as: `glusterd --xlator-option
*.upgrade=on -N /dev/null 21` ?
I think it would be nicer to use --log-level=/dev/null
On 29 Apr 2015, at 12:30, Justin Clift jus...@gluster.org wrote:
Reminder!!!
The weekly Gluster Community meeting is in 30 mins, in
#gluster-meeting on IRC.
This is a completely public meeting, everyone is encouraged
to attend and be a part of it. :)
Thanks for everyone for attending!
*
On 04/29/2015 08:57 AM, Benjamin Turner wrote:
Doh my mistake, I thought it was merged. I was just running with the
upstream 3.7 daily. Can I use this run as my baseline and then I can
run next time on the patch to show the % improvement? I'll wipe
everything and try on the patch, any idea
Hi everyone,
We've scheduled a Hangout session tomorrow about NFS-Ganesha features in
GlusterFS 3.7.
This session would include a preview of the features and a quick demo of
active/active HA implementation.
Please plan to join the Hangout session
https://plus.google.com/events/c9omal636
Hi everyone,
We've scheduled an Hangout session tomorrow about NFS-Ganesha features in
GlusterFS 3.7.
This session would include a preview of the features and a quick demo of
active/active HA implementation.
Please plan to join the Hangout session
https://plus.google.com/events/c9omal636
Sweet! Here is the baseline:
[root@gqas001 ~]# gluster v rebalance testvol status
Node Rebalanced-files size
scanned failures skipped status run time in
secs
- ---
All,
I am taking a shot at providing developer documentation[1] for the 'mystic'
syncop framework. People who care for this, please provide feedback to help
improve the content.
[1] - http://review.gluster.com/10365
cheers,
~KP
___
Gluster-devel
If we were to run without `-N`, in daemon mode, yum wouldn't know when
glusterd actually finished the upgrade process. Yum would consider the
parent process returning to be the end.
On Wed, Apr 29, 2015 at 9:17 PM, Raghavendra Talur rta...@redhat.com wrote:
Hi,
As part of the yum upgrade
Hi
Here is NetBSD regression status update for broken tests:
- tests/basic/afr/split-brain-resolution.t
Anuradha Talur is working on it, the change being still under review
http://review.gluster.org/10134
- tests/basic/ec/
This works but with rare spurious faiures. Nobody works on it.
-
Hello
NetBSD (and any non Linux system) was broken by this change that
introduce linux specific ENOKEY:
http://review.gluster.org/9918
Proposed fix is to turn it into EINVAL:
http://review.gluster.org/10456
This should be addressed quickly, as no change will pass NetBSD
regression until it is
On 04/30/2015 08:44 AM, Emmanuel Dreyfus wrote:
Hi
Here is NetBSD regression status update for broken tests:
- tests/basic/afr/split-brain-resolution.t
Anuradha Talur is working on it, the change being still under review
http://review.gluster.org/10134
- tests/basic/ec/
This works but with
Pranith Kumar Karampuri pkara...@redhat.com wrote:
On a related note, I see glupy is failing spuriously as well:
Know anything about it?
glupy.t used to work and was broken quite recenly. My investigation led
to a free on an invalid pointer, but I am not able to reproduce it
reliabily.
--
On 04/30/2015 10:02 AM, Emmanuel Dreyfus wrote:
Pranith Kumar Karampuri pkara...@redhat.com wrote:
On a related note, I see glupy is failing spuriously as well:
Know anything about it?
glupy.t used to work and was broken quite recenly. My investigation led
to a free on an invalid pointer,
On 04/30/2015 01:04 AM, Niels de Vos wrote:
On Wed, Apr 29, 2015 at 09:14:37PM +0200, Niels de Vos wrote:
On Wed, Apr 29, 2015 at 12:30:20PM -0400, Kaleb S. KEITHLEY wrote:
Any reason you don't want to run it as: `glusterd --xlator-option
*.upgrade=on -N /dev/null 21` ?
I think it would
On 30/04/15 09:18, Pranith Kumar Karampuri wrote:
On 04/30/2015 08:44 AM, Emmanuel Dreyfus wrote:
Hi
Here is NetBSD regression status update for broken tests:
- tests/basic/afr/split-brain-resolution.t
Anuradha Talur is working on it, the change being still under review
Hi,
Looks like the URL wasn't complete , sorry about that.
Please find the correct link here,
https://plus.google.com/events/c9omal6366f2cfkcd0iuee5ta1o
Thanks
Meghana
- Original Message -
From: Meghana Madhusudhan mmadh...@redhat.com
To: gluster-devel@gluster.org
Cc:
37 matches
Mail list logo
