[Gluster-devel] Improvement of eager locking
Hi, currently eager locking is implemented by checking the open-fd-count special xattr for each write. If there's more than one open on the same file, eager locking is disabled to avoid starvation. This works quite well for file writes, but makes eager locking unusable for other request types that do not involve an open fd (in fact, this method is only for writes on regular files, not reads or directories). This may cause a performance problem for other operations, like metadata. To be able to use eager locking for other purposes, what do you think about this proposal: Instead of implementing open-fd-count on posix xlator, do something similar but in locks xlator. The difference will be that locks xlator can use the pending locking information to determine if there are other processes waiting for a resource. If so, set a flag in the cbk xdata to let high level xlators know that they should not use eager locking (this can be done only upon request by xdata). I think this way provides a more precise way to avoid starvation and maximize performance at the same time, and it can be used for any request even if it doesn't depend on an fd. Another advantage is that if one file has been opened multiple times but all of them from the same glusterfs client, that client could use a single inodelk to manage all the accesses, not needing to release the lock. Current implementation in posix xlator cannot differentiate from opens from the same client or different clients. What do you think ? Xavi ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] An interesting take on GoTo statement by Dijkstra -
Since the goto idiom that Gluster uses generates the same code — which is what matters — I gave up my short-lived battle for not using it. One handy rule of thumb is based on whether a goto is forward or back, in (to a loop or other control contruct) or out. Forward and out are generally OK - no worse than extra state flags and better than code duplication - so they generally don't bother me. A handful of times in my entire career, I've seen a backward goto that was (weakly) justified. I've never seen an inward goto that was anything but pure evil, and I don't expect to. Fortunately, many people don't even know they're possible, so they're rare. ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] An interesting take on GoTo statement by Dijkstra -
On 01/15/2015 08:02 AM, Nagaprasad Sathyanarayana wrote:
On 15-Jan-2015, at 5:38 pm, Vijay Bellur vbel...@redhat.com wrote:
On 01/15/2015 12:13 PM, Nagaprasad Sathyanarayana wrote:
In a quest to find why good programmers are wary of the Go To
statement, came across this interesting article by /Edsger W. Dijkstra/ .
http://www.u.arizona.edu/~rubinson/copyright_violations/Go_To_Considered_Harmful.html.
goto statements that cause one to go back forth across the code are annoying
to me. However, if goto statements are used to return control from a common point
within a function, they enhance readability and also help in ensuring that we
perform necessary cleanup/terminal actions for a function in a single place.
It is to be noted that Dijkstra's article appeared before C was invented. If
you are interested in understanding more about goto, Knuth's paper titled
Structured Programming with go to statements [1] and a lkml thread on the same
[2] can be helpful.
FWIW, if you consider the trivial example:
#include stdio.h
void
Goto(int ctl)
{
if (ctl == 0) {
printf (foo\n);
goto out;
}
if (ctl == 1) {
printf (bar\n);
goto out;
}
if (ctl == 2) {
printf (baz\n);
goto out;
}
printf (nothing happened\n);
out:
printf (returning\n);
}
void
StructuredGoto(int ctl)
{
do {
if (ctl == 0) {
printf (foo\n);
break;
}
if (ctl == 1) {
printf (bar\n);
break;
}
if (ctl == 2) {
printf (baz\n);
break;
}
printf (nothing happened\n);
} while (0);
printf (returning\n);
}
If you compile to assembly, both functions generate exactly the same
code, both with and without optimization. (gcc-4.9.2, clang-3.4)
Gluster prefers the use of goto as it eliminates a level of indentation.
We have a somewhat artificial limit of 80 columns and functions that
have too many levels of indention will get kicked out in review.
Since the goto idiom that Gluster uses generates the same code — which
is what matters — I gave up my short-lived battle for not using it.
--
Kaleb
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] volume-status.t failure debugging in netbsd
Hi Emmanuel, To debug the volume-status.t failure in netbsd for the regression run [1] I was trying to download the log archive however was not able to connect to the machine. Can you please help me on getting the log file, is the server not responsive? ~Atin ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] volume-status.t failure debugging in netbsd
Missed out the link, here it goes [1] http://build.gluster.org/job/rackspace-netbsd7-regression-triggered/662/consoleFull ~Atin On 01/16/2015 10:38 AM, Atin Mukherjee wrote: Hi Emmanuel, To debug the volume-status.t failure in netbsd for the regression run [1] I was trying to download the log archive however was not able to connect to the machine. Can you please help me on getting the log file, is the server not responsive? ~Atin ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] volume-status.t failure debugging in netbsd
Atin Mukherjee amukh...@redhat.com wrote: To debug the volume-status.t failure in netbsd for the regression run [1] I was trying to download the log archive however was not able to connect to the machine. You can connect as user jenkins with the usual password. But here it is: http://ftp.espci.fr/shadow/manu/glusterfs-logs-20150115155454.tgz You can also use nbslave70 to test things, it does not run automatic regression. Currently it is running a test for me but feel free to kill it, I will restart later; -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] An interesting take on GoTo statement by Dijkstra -
Thanks Vijay for sharing these. Very informative. Thanks Naga On 15-Jan-2015, at 5:38 pm, Vijay Bellur vbel...@redhat.com wrote: On 01/15/2015 12:13 PM, Nagaprasad Sathyanarayana wrote: In a quest to find why good programmers are wary of the Go To statement, came across this interesting article by /Edsger W. Dijkstra/ . http://www.u.arizona.edu/~rubinson/copyright_violations/Go_To_Considered_Harmful.html. goto statements that cause one to go back forth across the code are annoying to me. However, if goto statements are used to return control from a common point within a function, they enhance readability and also help in ensuring that we perform necessary cleanup/terminal actions for a function in a single place. It is to be noted that Dijkstra's article appeared before C was invented. If you are interested in understanding more about goto, Knuth's paper titled Structured Programming with go to statements [1] and a lkml thread on the same [2] can be helpful. Cheers, Vijay [1] http://dl.acm.org/citation.cfm?id=356640dl=ACMcoll=DLCFID=472165232CFTOKEN=27447667 (needs access to ACM) [2] http://koblents.com/Ches/Links/Month-Mar-2013/20-Using-Goto-in-Linux-Kernel-Code/ ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] OperatingVersion in 3.6.1
At least two users [1] are reporting that the operating version [2] should be 30600 in 3.6.1 and not 30601 as convention might have it. I don't care either way actually, but I just wanted to confirm this isn't a bug in 3.6.1 so that I can patch puppet-gluster correctly. Cheers, James [1] 15:05 jackdpeterson @purpleidea cc JoeJulian https://gist.github.com/jackdpeterson/aad48879a9c2e02f0882 15:12 partner i can confirm the version is 30600 on debian jessie aswell for 3.6.1 15:14 partner and if i manually edit it to 30601 as was done on gist link the symptoms are the same ie. fails to start up the daemon 15:27 purpleidea partner: thanks for the info... 15:27 purpleidea JoeJulian is going to flip over this ;) [2] https://www.gluster.org/community/documentation/index.php/OperatingVersions signature.asc Description: This is a digitally signed message part ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Improvement of eager locking
On 01/15/2015 10:53 PM, Xavier Hernandez wrote: Hi, currently eager locking is implemented by checking the open-fd-count special xattr for each write. If there's more than one open on the same file, eager locking is disabled to avoid starvation. This works quite well for file writes, but makes eager locking unusable for other request types that do not involve an open fd (in fact, this method is only for writes on regular files, not reads or directories). This may cause a performance problem for other operations, like metadata. To be able to use eager locking for other purposes, what do you think about this proposal: Instead of implementing open-fd-count on posix xlator, do something similar but in locks xlator. The difference will be that locks xlator can use the pending locking information to determine if there are other processes waiting for a resource. If so, set a flag in the cbk xdata to let high level xlators know that they should not use eager locking (this can be done only upon request by xdata). I think this way provides a more precise way to avoid starvation and maximize performance at the same time, and it can be used for any request even if it doesn't depend on an fd. Another advantage is that if one file has been opened multiple times but all of them from the same glusterfs client, that client could use a single inodelk to manage all the accesses, not needing to release the lock. Current implementation in posix xlator cannot differentiate from opens from the same client or different clients. What do you think ? I like the idea. So basically we can propagate list_empty information of 'blocking_locks' list. And for sending locks, we need to use lk-owner based on gfid so that locks from same client i.e. lkowner+transport are granted irrespective of conflicting locks. The respective xls need to make sure to order the fops so that they don't step on each other in a single process. This can be used for entry-locks also. Pranith Xavi ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
