Posted changes for review,
https://review.gluster.org/10425
https://review.gluster.org/10426
~kaushal
On Tue, Apr 28, 2015 at 6:34 PM, Kaushal M kshlms...@gmail.com wrote:
After a long discussion (not really), we've concluded that a 64-bit
uint is really overkill for how we are using the
Hi all,
This meeting is scheduled for anyone that is interested in lssisting
with, or learning more about Bug Triage.
Meeting details:
- location: #gluster-meeting on Freenode IRC
( https://webchat.freenode.net/?channels=gluster-meeting )
- date: every Tuesday
- time: 12:00 UTC
AFAIU we've not officially supported 32-bit architectures for sometime
(possibly for ever) as a community. But we had users running it
anyway.
3.7 as it is currently, cannot run on 32-bit platforms. I've used
atomic operations which depend on specific processor instructions, to
increment a 64-bit
No Raspberry Pi servers any more?
On April 28, 2015 5:07:06 AM PDT, Justin Clift jus...@gluster.org wrote:
Does this mean we're officially no longer supporting 32 bit
architectures?
(or is that just on x86?)
+ Justin
On 28 Apr 2015, at 12:45, Kaushal M kshlms...@gmail.com wrote:
Found the
On Tue, Apr 28, 2015 at 12:58:24PM +0200, Niels de Vos wrote:
Hi all,
This meeting is scheduled for anyone that is interested in lssisting
with, or learning more about Bug Triage.
Meeting details:
- location: #gluster-meeting on Freenode IRC
(
On 04/28/2015 06:08 PM, Vijay Bellur wrote:
On 04/28/2015 05:48 PM, Kaushal M wrote:
AFAIU we've not officially supported 32-bit architectures for sometime
(possibly for ever) as a community. But we had users running it
anyway.
3.7 as it is currently, cannot run on 32-bit platforms. I've
On 04/28/2015 05:48 PM, Kaushal M wrote:
AFAIU we've not officially supported 32-bit architectures for sometime
(possibly for ever) as a community. But we had users running it
anyway.
3.7 as it is currently, cannot run on 32-bit platforms. I've used
atomic operations which depend on specific
After a long discussion (not really), we've concluded that a 64-bit
uint is really overkill for how we are using the generation number,
and I'll change it to a 32-bit uint. I'll send a change to do this
right away.
The generation number we use is not permanent, it is valid only within
a GlusterD
Does this mean we're officially no longer supporting 32 bit architectures?
(or is that just on x86?)
+ Justin
On 28 Apr 2015, at 12:45, Kaushal M kshlms...@gmail.com wrote:
Found the problem. The NetBSD slaves are running a 32-bit kernel and
userspace.
```
nbslave7a# uname -p
i386
```
On Tue, Apr 28, 2015 at 05:15:30PM +0530, Kaushal M wrote:
Because of this CAA_BITS_PER_LONG is set to 32 and the case for size 8
isn't compiled in uatomic_add_return. Even though the underlying
(virtual) hardware has 64-bit support, and supports the required
8-byte wide instrcution, it cannot
I seem to have found the issue.
The uatomic_add_return function is defined in urcu/uatomic.h as
```
/* uatomic_add_return */
static inline __attribute__((always_inline))
unsigned long __uatomic_add_return(void *addr, unsigned long val,
int len)
{
switch
Hi,
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);
On 04/28/2015 10:40 PM, Niels de Vos wrote:
On Tue, Apr 28, 2015 at 05:56:56PM +0100, Justin Clift wrote:
This sounds like it might be useful for us:
https://gerrit-documentation.storage.googleapis.com/Documentation/2.9.4/config-labels.html#label_copyAllScoresOnTrivialRebase
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 =
Hello All,
I was comparing the performance of different GlusterFS clients with each
other and came across an interesting result. I used fsync tester utility (
here https://oss.oracle.com/~mason/fsync-tester.c or here
https://github.com/gregsfortytwo/fsync-tester) which basically writes 1MB
to a
This sounds like it might be useful for us:
https://gerrit-documentation.storage.googleapis.com/Documentation/2.9.4/config-labels.html#label_copyAllScoresOnTrivialRebase
Yes/no/?
+ Justin
--
GlusterFS - http://www.gluster.org
An open source, distributed file system scaling to several
On Tue, Apr 28, 2015 at 05:56:56PM +0100, Justin Clift wrote:
This sounds like it might be useful for us:
https://gerrit-documentation.storage.googleapis.com/Documentation/2.9.4/config-labels.html#label_copyAllScoresOnTrivialRebase
label.Label-Name.copyAllScoresOnTrivialRebase
If true,
On Tue, Apr 28, 2015 at 12:15:11PM +0530, Atin Mukherjee wrote:
I see netbsd regression doesn't execute peer probe from any other tests
apart from mgmt_v3-locks.t, if it had that would have also failed. So
the conclusion is peer probe doesn't work in netbsd. Glusterd crashes
with following bt
On Tue, Apr 28, 2015 at 12:15:11PM +0530, Atin Mukherjee wrote:
I see netbsd regression doesn't execute peer probe from any other tests
apart from mgmt_v3-locks.t, if it had that would have also failed. So
the conclusion is peer probe doesn't work in netbsd.
It does not work anymore: that
On 04/28/2015 01:24 PM, Emmanuel Dreyfus wrote:
On Tue, Apr 28, 2015 at 12:15:11PM +0530, Atin Mukherjee wrote:
I see netbsd regression doesn't execute peer probe from any other tests
apart from mgmt_v3-locks.t, if it had that would have also failed. So
the conclusion is peer probe doesn't
On 04/28/2015 01:10 PM, Niels de Vos wrote:
On Tue, Apr 28, 2015 at 05:56:56PM +0100, Justin Clift wrote:
This sounds like it might be useful for us:
https://gerrit-documentation.storage.googleapis.com/Documentation/2.9.4/config-labels.html#label_copyAllScoresOnTrivialRebase
On 04/28/2015 01:40 PM, Emmanuel Dreyfus wrote:
On Tue, Apr 28, 2015 at 01:37:42PM +0530, Anand Nekkunti wrote:
__asm__ is for to write assembly code in c (gcc), __volatile__(:::)
compiler level barrier to force the compiler not to do reorder the
instructions(to avoid optimization ) .
22 matches
Mail list logo
