On Sun, Oct 12, 2014 at 08:07:07PM +0300, Alan Orth wrote:
Sorry, I'm a bit late on this. I quite like when you do a blog post
for the new releases, where you have a list of bugs squashed /
features added. You could do a blog post every week or two with a
summary of new / updated bugs, then
On Mon, Oct 13, 2014 at 12:39:33PM +0530, Pranith Kumar Karampuri wrote:
Op_errno is valid only if 'op_ret 0'. so that doesn't say much. After the
last readdir call with op_ret 0, there will be one more readdir call for
which op_ret will come as '0'. That means reading of the directory is
On 10/13/2014 01:14 PM, Emmanuel Dreyfus wrote:
On Mon, Oct 13, 2014 at 12:39:33PM +0530, Pranith Kumar Karampuri wrote:
Op_errno is valid only if 'op_ret 0'. so that doesn't say much. After the
last readdir call with op_ret 0, there will be one more readdir call for
which op_ret will come
On Mon, Oct 13, 2014 at 01:42:38PM +0530, Pranith Kumar Karampuri wrote:
No bug here, just suboptimal behavior, both in glusterfs and NetBSD FUSE.
oh!, but shouldn't it get op_ret = 0 instead of op_ret -1, op_errno EINVAL?
It happens because of thei change I introduced:
seekdir
On 10/13/2014 02:27 PM, Emmanuel Dreyfus wrote:
On Mon, Oct 13, 2014 at 01:42:38PM +0530, Pranith Kumar Karampuri wrote:
No bug here, just suboptimal behavior, both in glusterfs and NetBSD FUSE.
oh!, but shouldn't it get op_ret = 0 instead of op_ret -1, op_errno EINVAL?
It happens because of
On 10/13/2014 02:37 PM, Pranith Kumar Karampuri wrote:
On 10/13/2014 02:27 PM, Emmanuel Dreyfus wrote:
On Mon, Oct 13, 2014 at 01:42:38PM +0530, Pranith Kumar Karampuri wrote:
No bug here, just suboptimal behavior, both in glusterfs and NetBSD
FUSE.
oh!, but shouldn't it get op_ret = 0
On Mon, Oct 13, 2014 at 02:37:12PM +0530, Pranith Kumar Karampuri wrote:
I am not aware of backend filesystems that much, may be someone with that
knowledge can comment here, what happens when new entries are created in the
directory after this readdir is responded with '-1'?
In the meantime,
On 10/13/2014 02:45 PM, Emmanuel Dreyfus wrote:
On Mon, Oct 13, 2014 at 02:37:12PM +0530, Pranith Kumar Karampuri wrote:
I am not aware of backend filesystems that much, may be someone with that
knowledge can comment here, what happens when new entries are created in the
directory after this
On Mon, Oct 13, 2014 at 02:58:12PM +0530, Pranith Kumar Karampuri wrote:
I do not know :-(. Send the patch out for review, may be someone with this
knowledge can do the review...
Here it is:
http://review.gluster.org/8926
--
Emmanuel Dreyfus
m...@netbsd.org
On 10/13/2014 08:01 AM, Pranith Kumar Karampuri wrote:
hi,
Why are we moving away from this coding style?:
if (x) {
/*code*/
} else {
/* code */
}
This patch (in master) introduces the same and explains why,
commit 0a8371bdfdd88e662d09def717cc0b822feb64e8
Author: Jeff Darcy
On 10/13/2014 07:27 PM, Shyam wrote:
On 10/13/2014 08:01 AM, Pranith Kumar Karampuri wrote:
hi,
Why are we moving away from this coding style?:
if (x) {
/*code*/
} else {
/* code */
}
This patch (in master) introduces the same and explains why,
commit
On 10/13/2014 10:08 AM, Pranith Kumar Karampuri wrote:
On 10/13/2014 07:27 PM, Shyam wrote:
On 10/13/2014 08:01 AM, Pranith Kumar Karampuri wrote:
hi,
Why are we moving away from this coding style?:
if (x) {
/*code*/
} else {
/* code */
}
This patch (in master) introduces the same and
On 10/13/2014 06:19 PM, Emmanuel Dreyfus wrote:
Hello
Testing quota feature on NetBSD, I get strange results, I wonder if
this is what should happen.
If I set a directory quota to 4 MB, the start writing to it uwing
dd bs=1024k, I will get EDQUOTA after 15 blocks (that is 15 MB).
Is there a
+1 on choosing a single brace style [1] for the entire codebase.
[1]
http://en.wikipedia.org/wiki/Indent_style
- Original Message -
From: Shyam srang...@redhat.com
To: Pranith Kumar Karampuri pkara...@redhat.com, gluster-devel@gluster.org
Sent: Monday, October 13, 2014 10:13:38 AM
On 10/13/2014 07:43 PM, Shyam wrote:
On 10/13/2014 10:08 AM, Pranith Kumar Karampuri wrote:
On 10/13/2014 07:27 PM, Shyam wrote:
On 10/13/2014 08:01 AM, Pranith Kumar Karampuri wrote:
hi,
Why are we moving away from this coding style?:
if (x) {
/*code*/
} else {
/* code */
}
This
top post
ISTR we agreed to use Linux kernel style!
Which is
if (foo) {
/* ... */
} else {
/* ... */
}
I don't recall any discussion on -devel about changing this.
/top post
On 10/13/2014 11:05 AM, Pranith Kumar Karampuri wrote:
On 10/13/2014 07:43 PM, Shyam wrote:
Hello everyone,
I have cloned and built today's GlusterFS.
The test tests/basic/uss.t fails.
The console log and /var/log/glusterfs/mnt-glusterfs-0 attached.
Any ideas?
Thanks in advance,
Edward.=
TEST 75 (line 159): fd_close 5
ok 75
RESULT 75: 0
=
I urge you guys to notify others before making basic style
changes like this.
Yes, all style changes - including the one being enforced by the
original version of checkpatch.pl - should be submitted for review.
___
Gluster-devel mailing list
- Original Message -
+1 to existing Linux kernel style. Moreover, its a style which is used
heavily in existing code base. I don't see any advantage in changing the
style now.
It's not a change. It's already common in our code, if not actually the *most*
common style.
% find .
More recently, a *completely separate* approach to
multi-threading - multi-threaded epoll - has been getting some
attention. Here's what I see as the pros and cons of this new approach.
You forgot:
CON: epoll is Linux specific and code using it is not easily portable.
Excellent point.
On 10/13/2014 04:34 PM, Jeff Darcy wrote:
- Original Message -
+1 to existing Linux kernel style. Moreover, its a style which is used
heavily in existing code base. I don't see any advantage in changing the
style now.
It's not a change. It's already common in our code, if not
Not taking sides, though if I were I would support the kernel style
because I, personally, find it easier to read. Just to clarify the point:
$ find -name '*.c' | xargs grep '} else {' | wc -l
1284
$ find -name '*.c' | xargs grep else | grep -v '}' | wc -l
1646
On 10/13/2014 01:46 PM, Shyam
(apologies, last one on the metrics from me :), as I believe it is more
about style than actual numbers at a point)
_maybe_ this is better, and it is pretty close to call now ;)
find -name '*.c' | xargs grep else | wc -l
3719
find -name '*.c' | xargs grep else | grep '}' | wc -l
1986
find
On Mon, Oct 13, 2014 at 2:00 PM, Shyam srang...@redhat.com wrote:
(apologies, last one on the metrics from me :), as I believe it is more
about style than actual numbers at a point)
_maybe_ this is better, and it is pretty close to call now ;)
find -name '*.c' | xargs grep else | wc -l
Without taking sides: the last grep is including else without either { or }.
That's true. I stand corrected.
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Vijay Bellur vbel...@redhat.com wrote:
You would need to set features.soft-timeout and features.hard-timeout
values to 0 when testing with lower values of directory quota.
It works more like expected this way, but there are still oddities: for
instance once quota is reached, I can still append
26 matches
Mail list logo
