On 10/13/2014 12:19 PM, Emmanuel Dreyfus wrote:
On Mon, Oct 13, 2014 at 10:32:12AM +0530, Pranith Kumar Karampuri wrote:
End of directory is determined by 'op_ret == 0'.
I get op_ret > 0, op_errno == ENOENT at quota xlator level.
On my system with xfs
as backend, things are working fin
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:
seekdi
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 instea
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 re
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
_
hi,
Why are we moving away from this coding style?:
if (x) {
/*code*/
} else {
/* code */
}
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-devel
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 minimal granularity, or do I have a bug to fix?
-
On Monday 13 October 2014 05:31 PM, Pranith Kumar Karampuri wrote:
hi,
Why are we moving away from this coding style?:
if (x) {
/*code*/
} else {
/* code */
}
Pranith
For me the script that checks the coding style (checkpatch.pl - which is
present in the extras directory within the glust
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
Date: Mon
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 0a8371bdfdd88e662d09def717cc0b822f
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 mi
+1 on choosing a single brace style [1] for the entire codebase.
[1]
http://en.wikipedia.org/wiki/Indent_style
- Original Message -
> From: "Shyam"
> To: "Pranith Kumar Karampuri" , gluster-devel@gluster.org
> Sent: Monday, October 13, 2014 10:13:38 AM
> Subject: Re: [Gluster-devel] if/
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 pat
ISTR we agreed to use Linux kernel style!
Which is
if (foo) {
/* ... */
} else {
/* ... */
}
I don't recall any discussion on -devel about changing this.
On 10/13/2014 11:05 AM, Pranith Kumar Karampuri wrote:
On 10/13/2014 07:43 PM, Shyam wrote:
On 10/13/2014 10:0
+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.
On Mon, Oct 13, 2014 at 9:12 PM, Kaleb S. KEITHLEY
wrote:
>
>
> ISTR we agreed to use Linux kernel style!
>
> Which is
>
>if (foo) {
>
Good day, all
Just a reminder that we will be having a GlusterFS bug prioritization
meeting Tuesday 14-Oct-2014, 12:00 UTC.
More information available at :
http://blog.gluster.org/2014/10/whats-that-bug-to-you-glusterfs-bug-priority-meeting/
davemc
__
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
=
On Mon, Oct 13, 2014 at 10:05:27PM +0530, Raghavendra G wrote:
> +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.
I fully agree with this. Also, if changes are done, please update the
doc/
>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
G
- 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.
Excell
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 actually
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 wro
(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 -name
On Mon, Oct 13, 2014 at 2:00 PM, Shyam 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
> 3719
> find -nam
> 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 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 smal chunk to a
32 matches
Mail list logo
