Perl 6 - the future is here, just unevenly distributed

IRC log for #gluster-dev, 2015-07-22

| Channels | #gluster-dev index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:34 topshare joined #gluster-dev
00:38 topshare joined #gluster-dev
01:10 topshare joined #gluster-dev
02:13 an joined #gluster-dev
02:27 an joined #gluster-dev
03:12 vmallika joined #gluster-dev
03:13 overclk joined #gluster-dev
03:27 an joined #gluster-dev
03:40 shubhendu joined #gluster-dev
03:54 atinm joined #gluster-dev
04:02 itisravi joined #gluster-dev
04:04 kanagaraj joined #gluster-dev
04:05 krishnan_p joined #gluster-dev
04:32 ashishpandey joined #gluster-dev
04:44 vimal joined #gluster-dev
04:47 schandra joined #gluster-dev
04:59 hchiramm joined #gluster-dev
05:05 sakshi joined #gluster-dev
05:05 pppp joined #gluster-dev
05:05 ggarg joined #gluster-dev
05:06 hgowtham joined #gluster-dev
05:08 Manikandan joined #gluster-dev
05:08 ashiq joined #gluster-dev
05:11 ppai joined #gluster-dev
05:16 spandit joined #gluster-dev
05:17 jiffin joined #gluster-dev
05:17 deepakcs joined #gluster-dev
05:17 rafi joined #gluster-dev
05:18 ndarshan joined #gluster-dev
05:19 vmallika joined #gluster-dev
05:21 rafi1 joined #gluster-dev
05:24 gem joined #gluster-dev
05:30 Bhaskarakiran joined #gluster-dev
05:36 an joined #gluster-dev
05:40 anekkunt joined #gluster-dev
05:43 surabhi joined #gluster-dev
05:48 an joined #gluster-dev
05:52 kdhananjay joined #gluster-dev
06:00 gem joined #gluster-dev
06:02 Manikandan joined #gluster-dev
06:08 raghu joined #gluster-dev
06:10 soumya_ joined #gluster-dev
06:11 pranithk joined #gluster-dev
06:14 topshare joined #gluster-dev
06:15 nbalacha joined #gluster-dev
06:23 jiffin1 joined #gluster-dev
06:26 soumya joined #gluster-dev
06:30 gem joined #gluster-dev
06:31 Manikandan joined #gluster-dev
06:34 an joined #gluster-dev
06:39 ppai joined #gluster-dev
06:49 kshlm joined #gluster-dev
06:52 atalur joined #gluster-dev
07:07 atinm joined #gluster-dev
07:13 deepakcs joined #gluster-dev
07:16 an joined #gluster-dev
07:17 jiffin1 joined #gluster-dev
07:21 soumya_ joined #gluster-dev
07:26 rtalur joined #gluster-dev
07:32 soumya joined #gluster-dev
07:37 atinm joined #gluster-dev
07:41 rtalur joined #gluster-dev
07:47 topshare joined #gluster-dev
07:59 ppai joined #gluster-dev
08:17 aravindavk joined #gluster-dev
08:21 hchiramm_ joined #gluster-dev
08:38 mihaillive joined #gluster-dev
08:38 mihaillive Hi, does somebody have more information about sunrpc and porting it to x64
08:48 rtalur joined #gluster-dev
08:49 shubhendu joined #gluster-dev
08:57 an joined #gluster-dev
09:01 ndevos atinm, kshlm, overclk, kkeithley: I'm off todays afternoon and will not be able to host the weekly meeting, please find someone for it :)
09:03 mihaillive joined #gluster-dev
09:05 rtalur joined #gluster-dev
09:06 josferna joined #gluster-dev
09:08 Saravana_ joined #gluster-dev
09:08 ppai joined #gluster-dev
09:10 Manikandan joined #gluster-dev
09:13 schandra joined #gluster-dev
09:19 krishnan_p joined #gluster-dev
09:20 byreddy joined #gluster-dev
09:21 ndevos krishnan_p, rtalur, itisravi: I'm off todays afternoon and will not be able to host the weekly meeting, please find someone for it :)
09:22 * ndevos tried earlier with some others, but did not see a reply yet...
09:22 itisravi ndevos: I'll ask around :)
09:22 ndevos itisravi++ thanks!
09:22 glusterbot ndevos: itisravi's karma is now 11
09:23 shubhendu joined #gluster-dev
09:27 Manikandan joined #gluster-dev
09:28 sakshi joined #gluster-dev
09:35 atinm ndevos, sorry, I didn't see your ping
09:35 glusterbot atinm: Please don't naked ping. http://blogs.gnome.org/mark​mc/2014/02/20/naked-pings/
09:36 ndevos atinm: no problem, there are others (one!) that responded :)
09:45 itisravi atinm: so are you hosting the meeting today?
09:45 ndevos hehe
09:45 atinm itisravi, :)
09:45 itisravi ;)
09:59 ppai joined #gluster-dev
09:59 krishnan_p joined #gluster-dev
10:05 an joined #gluster-dev
10:26 atalur xavih, this is pranith. I was going over the txn frame work pseudo code you sent along with Anuradha. So it seems like you merged the idea of having a separate xlator and also there seems to be apis?
10:28 shubhendu_ joined #gluster-dev
10:29 shubhendu joined #gluster-dev
10:32 itisravi joined #gluster-dev
10:33 sakshi joined #gluster-dev
10:33 atalur xavih, I actually liked your earlier idea of not having a separate xlator...
10:35 atalur xavih, let me send a mail with what I had in mind after our earlier discussions...
10:36 shubhendu joined #gluster-dev
10:37 xavih atalur: without any additional xlator, you loose a lot of advantages, unless you implement it inside protocol/client
10:47 pranithk xavih: hey!
10:47 pranithk xavih: what kind of advantages?
10:48 xavih pranithk: one of the most important is that transaction management won't require callbacks on the user side. This simplifies code a lot and makes it much more readable
10:49 xavih pranithk: you can create a transaction and immediately start winding the request to lower xlators
10:49 xavih pranithk: it's even simpler because the gf_txn_prepare() call that I talked yesterday is not really needed. It can all be done in gf_txn_create()
10:50 pranithk xavih: Hmm...
10:50 pranithk xavih: who manages the txn? the user xlator?
10:51 pranithk xavih: I mean, the optimization part of inodelk etc is done by which xlator?
10:52 ira joined #gluster-dev
10:52 xavih pranithk: no, the user xlator only creates a transaction if it needs one. Once this transaction reaches the txn-xlator, all logic will begin (though most of them will be handled in a library). The txn-xlator is only needed to take care of the incoming requests
10:53 xavih pranithk: the txn-xlator is used to avoid the use of callbacks in the user xlator
10:54 xavih pranithk: I think it's better to have a single xlator that needs to deal with callbacks than force all cluster xlators to implement callbacks
10:54 pranithk xavih: I agree.
10:54 pranithk xavih: let me see if I understood what you are saying
10:54 pranithk xavih: writev comes to afr
10:55 pranithk xavih: afr creates txn, then winds xattrop to mark trusted.afr.dirty. txn-xlator sees that the inodelks are not done and winds inodelk?
10:56 xavih pranithk: yes
10:57 xavih pranithk: however I think it will be interesting to also move the health logic (or at least part) of this to the txn-xlator. I mean xattrop and some other things
10:57 pranithk xavih: so afr at the end of its txn, will do a release and then, how will this lead to unlock in txn-xlator?
10:57 pranithk xavih: I have some ideas
10:58 pranithk xavih: we need a way to store ctx in the txn structure...
10:58 pranithk xavih: if we get to re-use lock, we should also get to re-use the ctx
10:58 pranithk xavih: I still need to think a bit more....
10:59 pranithk xavih: I am just beginning to understand your pseudo code :-)
10:59 xavih pranithk: when gf_txn_release() has been called for every wound request, the library will know the request is not needed anymore and will mark the inode as "not used". So the library (on behalf of the txn-xlators) will initiate the unlocks when appropriate
11:00 xavih pranithk: keep in mind that all logic and needed information will be in the library, not in the txn-xlators. txn-xlators will be used to register which subvolumes are used by a transaction and which inodes are involved
11:00 pranithk xavih: what if after all the wound requests are 'gf_txn_release'ed we want to wind some more requests in same txn?
11:01 pranithk xavih: for example. after create of txn in writev
11:01 xavih pranithk: I knew you were to ask this :P
11:01 pranithk xavih: :-)
11:02 pranithk xavih: I may have to start for home in 10 minutes.... just letting you know...
11:03 xavih pranithk: in the what I've had explained till now, this is not possible. I'm thinking in creating a gf_txn_destroy() to really dispose the transaction, so it can be reused. However this has some limitations. For example the inodes involved in the requests should be the same
11:04 xavih pranithk: I didn't talk about that because I still need to solve some details in that case
11:04 pranithk xavih: don't link txn and lock. txn structure should embed locks. Then we can re-use them without bothering what is happening to transaction...
11:04 atalur xavih, I thought gf_txn_release() would just inform txn-xlator that the intiator xlator is done for now but txn-xlator will still keep it intact in case future requests arrive.
11:05 xavih pranithk: yes, yes, that was the idea
11:05 pranithk xavih: then I think we are good to go?
11:05 mihaillive joined #gluster-dev
11:05 xavih pranithk: but once a transaction is created, locks are bound to the transactions, and we need to know when the transaction is finished to mark those locks are unlockable...
11:06 pranithk xavih: one way is to say, txn_create. After txn is done, txn_destroy
11:07 pranithk xavih: Meanwhile txn can choose to store ctx inside the locks. i.e. the ctx can be trusted as long as the lock is active.
11:07 xavih atalur: we need something else, otherwise the txn-xlator won't know when it can unlock a lock because it doesn't know if the user xlator will send more requests or not
11:07 xavih pranithk: yes
11:07 pranithk xavih: this ctx can be useful for remembering the things like ec versions etc?
11:09 xavih pranithk: I think we should think in a more generic implementation that allows more use cases...
11:09 dlambrig joined #gluster-dev
11:09 atalur xavih, of course. my understanding was that a transaction can't be preserved forever so either something like a destroy/or a timeout should do it
11:10 atalur xavih, by it I mean unlock
11:10 xavih pranithk: transactions are short lived. What could last more time is the lock itself
11:11 xavih pranithk: many transactions can make use of the same lock at the same time
11:11 ppai joined #gluster-dev
11:11 pranithk xavih: yeah...
11:11 xavih pranithk: I'm planning to also add the concept of shared and exclusive lock. This will control if requests can be sent in parallel or sequentially for a given lock
11:11 pranithk xavih: sure
11:12 pranithk xavih: okay I gotta run now. Let me also think about these things. I will respond on your mail with ideas.
11:12 pranithk xavih: cya! have a nice day
11:12 xavih pranithk: sure. See you :)
11:14 mihaillive Does somebody of you have some experience with sunrppc
11:29 rafi joined #gluster-dev
11:34 kshlm mihaillive, What do you need to know? I've not got an in-depth understanding of sunrpc, but I can try to help.
11:35 mihaillive I found that 64 bit implementation keep long to be long and does not change it like in mac os to int
11:35 shyam joined #gluster-dev
11:36 kotreshhr joined #gluster-dev
11:36 mihaillive Example sizeof rpc_msg.rm_xid for 64 bit Fedora  returns 8 bytes, when in Mac OS X 10.10 is 4 bytes.
11:37 mihaillive it means that there will be difference if this 2 machines start to talk eachother
11:37 mihaillive Do you know why glibc ported it like this?
11:41 rafi joined #gluster-dev
11:49 rafi joined #gluster-dev
11:49 overclk joined #gluster-dev
11:53 kkeithley milhaillive: that's a question for the glibc developers.
12:01 mihaillive kkeithley: you are right, but seems most of them are in vacation
12:05 krishnan_p The gluster weekly community meeting has started at #gluster-meeting.
12:35 kotreshhr left #gluster-dev
12:52 kdhananjay joined #gluster-dev
12:53 an joined #gluster-dev
13:06 samikshan joined #gluster-dev
13:08 overclk joined #gluster-dev
13:22 soumya joined #gluster-dev
13:24 overclk joined #gluster-dev
13:49 overclk joined #gluster-dev
13:53 shubhendu joined #gluster-dev
13:56 sankarshan_ joined #gluster-dev
13:57 dlambrig joined #gluster-dev
14:00 overclk joined #gluster-dev
14:02 overclk raghu: ping. can you merge http://review.gluster.org/#/c/11653/ please.
14:02 shyam joined #gluster-dev
14:03 pousley joined #gluster-dev
14:24 dlambrig joined #gluster-dev
14:27 wushudoin| joined #gluster-dev
14:28 nbalacha joined #gluster-dev
14:37 overclk joined #gluster-dev
14:40 overclk_ joined #gluster-dev
14:44 ggarg joined #gluster-dev
14:47 lpabon joined #gluster-dev
15:10 skoduri joined #gluster-dev
15:16 obnox joined #gluster-dev
15:19 vmallika joined #gluster-dev
15:24 shyam joined #gluster-dev
15:25 cholcombe joined #gluster-dev
15:25 dlambrig joined #gluster-dev
15:36 skoduri joined #gluster-dev
15:41 overclk joined #gluster-dev
15:48 an joined #gluster-dev
15:54 hchiramm_ joined #gluster-dev
16:00 deepakcs joined #gluster-dev
16:07 rafi joined #gluster-dev
16:26 dlambrig left #gluster-dev
16:36 jiffin joined #gluster-dev
16:38 an joined #gluster-dev
16:39 pousley joined #gluster-dev
16:41 overclk joined #gluster-dev
16:49 shyam joined #gluster-dev
17:00 overclk joined #gluster-dev
17:01 pppp joined #gluster-dev
17:01 gem joined #gluster-dev
17:10 overclk joined #gluster-dev
17:15 cholcombe joined #gluster-dev
17:26 _Bryan_ joined #gluster-dev
17:36 an joined #gluster-dev
18:15 dlambrig joined #gluster-dev
18:25 vimal joined #gluster-dev
18:49 wushudoin| joined #gluster-dev
18:54 wushudoin| joined #gluster-dev
18:56 RedW joined #gluster-dev
18:58 RedW joined #gluster-dev
20:21 mihaillive joined #gluster-dev
20:21 mihaillive Does somebody know which implementation of rpc gluster is using?
20:22 mihaillive one from glibc or libtirpc
20:56 badone joined #gluster-dev
21:14 shyam joined #gluster-dev
21:32 shyam joined #gluster-dev
22:05 jbautista- joined #gluster-dev
22:10 jbautista- joined #gluster-dev
22:29 shyam joined #gluster-dev

| Channels | #gluster-dev index | Today | | Search | Google Search | Plain-Text | summary