Perl 6 - the future is here, just unevenly distributed

IRC log for #gluster-dev, 2017-02-13

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

All times shown according to UTC.

Time Nick Message
00:43 gyadav joined #gluster-dev
01:00 gyadav joined #gluster-dev
01:20 gyadav joined #gluster-dev
01:21 loadtheacc joined #gluster-dev
01:47 gem joined #gluster-dev
02:22 ChatSharp joined #gluster-dev
02:25 ChatSharp left #gluster-dev
03:32 nthomas joined #gluster-dev
03:33 skoduri joined #gluster-dev
03:44 Shu6h3ndu joined #gluster-dev
03:47 magrawal joined #gluster-dev
03:47 mchangir joined #gluster-dev
03:53 gyadav joined #gluster-dev
03:55 kdhananjay joined #gluster-dev
03:56 atinm joined #gluster-dev
04:35 nbalacha joined #gluster-dev
04:46 rafi joined #gluster-dev
05:09 ppai joined #gluster-dev
05:12 apandey joined #gluster-dev
05:14 ndarshan joined #gluster-dev
05:15 nbalacha joined #gluster-dev
05:20 ashiq joined #gluster-dev
05:21 prasanth joined #gluster-dev
05:23 hgowtham joined #gluster-dev
05:29 Shu6h3ndu joined #gluster-dev
05:30 jiffin joined #gluster-dev
05:42 ankit_ joined #gluster-dev
05:43 skoduri joined #gluster-dev
05:44 Humble joined #gluster-dev
05:44 ankit__ joined #gluster-dev
05:46 susant joined #gluster-dev
05:47 mchangir joined #gluster-dev
05:55 Saravanakmr joined #gluster-dev
06:01 rjoseph joined #gluster-dev
06:02 riyas joined #gluster-dev
06:03 ppai joined #gluster-dev
06:05 riyas joined #gluster-dev
06:05 susant joined #gluster-dev
06:07 jiffin1 joined #gluster-dev
06:08 aravindavk joined #gluster-dev
06:12 asengupt joined #gluster-dev
06:12 karthik_us joined #gluster-dev
06:26 poornima joined #gluster-dev
06:26 k4n0 joined #gluster-dev
06:44 k4n0 joined #gluster-dev
06:53 gyadav_ joined #gluster-dev
06:56 nbalacha joined #gluster-dev
07:04 wdfwefewvfgew joined #gluster-dev
07:04 wdfwefewvfgew left #gluster-dev
07:07 pranithk1 joined #gluster-dev
07:20 apandey joined #gluster-dev
07:21 skumar joined #gluster-dev
07:41 magrawal joined #gluster-dev
07:42 msvbhat joined #gluster-dev
07:42 pranithk1 xavih: hey, could you let us know if it is a good time to talk to you about transaction framework?
07:43 kdhananjay joined #gluster-dev
07:45 xavih pranithk1: we can talk now if you want
07:45 pranithk1 xavih: cool
07:46 pranithk1 xavih: So we just discussed about your mail
07:46 pranithk1 xavih: So you are in agreement that we need to create sub-transactions one after the other and not at the start itself... right?
07:47 xavih pranithk1: yes, for each of the sub operations for a given operation
07:47 pranithk1 xavih: cool
07:48 xavih pranithk1: I was thinking that the main transaction is not really needed is we are sure that an upper xlator already uses a transaction for the operation. For exame if fuse xlator would use a transactions for each fop, them afr/ec wouldn't need to create the main transacition...
07:48 pranithk1 xavih: okay got it...
07:50 pranithk1 xavih: We will come to this fuse creating main_txn also... we have some doubts.
07:51 kdhananjay xavih: so heres another example from the notes - one of sharding requiring an atomic write that spreads across multiple shards.
07:52 kdhananjay xavih: the example had a single write spreading across three different shards but they all need to be written to atomically as a single transaction.
07:53 kdhananjay xavih: the notes had, in your handwriting, a parent transaction and 3 sub-txns branching from it represented in a picture - subtxn1, subtxn2 and subtxn3
07:53 xavih kdhananjay: yes, it's the same case, but here the sub-transactions corresponding to the 3 writes can be created and processed in parallel
07:53 xavih kdhananjay: yes
07:54 pranithk1 xavih: one second thinking
07:56 pranithk1 xavih: We are just checking to see the locking part in the case of sharding example
07:57 xavih pranithk1: you don't need to lock anything. The transaction will take care of it
07:57 xavih pranithk1: from the point of view of sharding, only transactions need to be created
07:58 pranithk1 xavih: yes, but how will the library do the locking, i.e. at which point?
07:58 xavih pranithk1: the txn framework will wait until all branches of a transaction are ready before starting any useful work
07:58 xavih pranithk1: the main txn will wait for all sub-txn to be ready
07:59 xavih pranithk1: and each sub-txn will be ready when it has created all its branches and each branch has determined which resources it needs (inode basically)
07:59 xavih pranithk1: so, the txn library will know exactly what inodes it needs to lock when the main txn is ready
08:00 xavih pranithk1: at this point, all inodes involved will be acquired
08:00 xavih pranithk1: if a single inodelk fails, the whole operation is aborted
08:00 pranithk1 xavih: okay thinking
08:02 xavih pranithk1: the txn library doesn't anything until the toplevel transaction is ready
08:02 pranithk1 xavih: okay
08:03 pranithk1 xavih: Will the fop be wound on main transaction or sub-transaction?
08:03 pranithk1 xavih: Is main transaction dummy?
08:03 magrawal joined #gluster-dev
08:04 pranithk1 xavih: Just a place holder?
08:04 pranithk1 xavih: It just encompasses all the subtransactions which actually do the fops...
08:07 xavih pranithk1: not really. It's like a container with subcontainers. Each transaction only serves as a conceptual grouping with some assigned resources (txn are resources themselves). Once you have all the components related to the main transaction, work can begin. At this point I'm not sure if we can say that fops will be wound on any transaction. Conceptually we can say that they are related to its own txn, but the wound is made on behalf of one of the
08:07 xavih xlators of the graph
08:08 magrawal_ joined #gluster-dev
08:08 xavih pranithk1: transactions take care of acquiring some resources to execute something in an atomic way. Once this is achieved, the fop is executed, but I wouldn't say that it's executed by a transaction
08:09 pranithk1 xavih: okay got it.
08:09 pranithk1 xavih: Let me ask the question this way
08:09 xavih pranithk1: not sure if this answers yout question or you were asking something else...
08:10 pranithk1 xavih: When afr_writev() comes we can create one transaction. and start it right? Why do we have to create a main transaction and then a subtransaction?
08:10 pranithk1 xavih: by starting it I meant winding the fop in the statement above
08:11 xavih pranithk1: this is what I was saying at the beginning. If we are sure that there exists a parent transaction, the afr_write() doesn't need to create the main transaction. All pre-op/op/post-op transactions will be sub-transaction of another txn, so there's no need to create another one in afr itself
08:12 xavih pranithk1: yes, once we are inside a txn, the fop can be simply wound
08:13 pranithk1 xavih: okay in afr_writev() we need to perform pre-op, op, post-op
08:13 xavih pranithk1: in the case of afr, you will need to create a pre-op txn and wound the fop. Once it's finished, you'll create another txn and wind the main fop, ...
08:13 xavih pranithk1: only limitation is that other txn cannot use new resources
08:14 pranithk1 xavih: so the main fop's transaction will be child of pre-op txn right?
08:14 xavih pranithk1: but I this is already satisfied now
08:14 xavih pranithk1: no, no, when the callback for the transaction is called, this transaction is already finished
08:15 xavih pranithk1: if another transaction is created, it will be child of the same parent
08:15 xavih pranithk1: suppose shard creates a txn
08:15 pranithk1 xavih: wait wait
08:15 pranithk1 xavih: I think we are confused about afr itself
08:16 kdhananjay xavih: but doesnt finishing of the first transaction include releasing of hte locks it acquired?
08:16 kdhananjay xavih: we thought thats what marks the "end" of a transaction?
08:16 xavih kdhananjay: no, at least until the callback of the transaction returns
08:16 xavih kdhananjay: the transaction is already terminated, but won't release anything until the callback also terminated
08:17 xavih kdhananjay: so the callback can be used to create more sub-txn
08:17 kdhananjay xavih: ah! you mean something like the gf_txn_commit() which is for the requesting translator to call whenever it thinks it needs to terminate the txn (which the txn library will internally interpret as "release all acquired resources"?
08:18 kdhananjay xavih: in this case its for afr to call it whenever it thinks its appropriate
08:19 xavih kdhananjay: let me see where we were using the gf_txn_commit() function... I don't remember...
08:19 apandey_ joined #gluster-dev
08:21 xavih kdhananjay: you are right, we can use gf_txn_commit()/gf_txn_rollback() to explicitly finishing a transaction, but this should only happen once we are sure that all sub-txn have finished. I think the only safe place to do that is in the termination callback of the sub-txn
08:22 xavih kdhananjay: note that even if gf_txn_commit() is called, the txn library probably won't immediately release the locks it already has
08:22 kdhananjay xavih: eager lock?
08:22 msvbhat joined #gluster-dev
08:22 xavih kdhananjay: yes
08:23 xavih kdhananjay: but the user of the txn framework doesn't need to think about this. It only needs to communicate when it has finished using the resources
08:25 pranithk1 xavih: kdhananjay: Let me write pseudo code for afr_writev() and give you what I think
08:25 xavih pranithk1: ok
08:32 pranithk1 xavih: https://paste.fedoraproject.org/556734/97476814
08:33 pranithk1 xavih: this is for afr_writev() without any parent transaction from either shard/writev
08:33 pranithk1 xavih: It is serial txn
08:34 xavih pranithk1: if we are not sure if there will be a parent txn, we will need to create it explicitly...
08:34 pranithk1 xavih: Okay could you modify the code to add what you mean please
08:34 xavih pranithk1: the only detail is that I would call txn_commit() before unwinding
08:34 xavih pranithk1: ok
08:35 pranithk1 xavih: okay modify the code with your comments.., that would clarify things IMO
08:35 pranithk1 xavih: use fpaste to upload...
08:40 rafi joined #gluster-dev
08:40 xavih pranithk1: https://paste.fedoraproject.org/556739/97522914/
08:42 pranithk1 xavih: okay. How will this code be if there is already parent transaction? i.e. in shard xlator or something
08:42 pranithk1 xavih: Will the code change?
08:43 xavih pranithk1: no, it's the same, but without the creation of main_txn and without the afr_writev_txn_cbk() function
08:44 pranithk1 xavih: hmm... who will unwind it from afr?
08:44 xavih pranithk1: oh, I see...
08:44 xavih pranithk1: sorry. In this case you need to unwind from postop_txn_cbk
08:45 pranithk1 xavih: In that case why do we need main_txn?
08:45 pranithk1 xavih: this is what kdhananjay has been saying
08:46 pranithk1 xavih: kdhananjay says we need main_txn definitely when we wind something in parallel. Because it has to keep track of the completion of leaves
08:47 xavih pranithk1: because without a main transaction, each of pre_op, op and post_op will be executed atomically, but not all 3. So if another pre_op from another client comes between pre_op and op, it will be executed. No transaction protects that
08:48 xavih kdhananjay: when the callback of the txn is processed, the transaction is already finished. It has already failed or succeeded, so we cannot create new transactions as sub-txn of this one. We can only create new transactions of the parent, that is still being processed
08:49 xavih kdhananjay: how would we handle the failure of a sub-txn on a txn that has already succeeded ?
08:50 kdhananjay xavih: oh so you are implying that as soon as line 3 and 4 of the pseudocode modification that you gave are executed, it implicitly creates a dependency or a sort of a parent-child relationship between @main_txn and @preop_txn?
08:51 xavih kdhananjay: yes. We only have one "active" transaction. I used xdata to keep track of the active transaction (not sure yet if it's the best place). When we create a transaction we look at the xdata to determine the parent txn
08:52 xavih kdhananjay: this automatically creates dependencies between txns
08:54 xavih kdhananjay: this is not needed when all txns are created by the same xlator, but since we must support nested txns from different xlators, storing it in xdata seems a good place
08:56 xavih kdhananjay: storing it in the call frame is another possibility, but I'm not sure if it can have unwanted side effects on parallel executions
08:56 kotreshhr joined #gluster-dev
09:00 kdhananjay xavih: ok let me try to rephrase my question
09:01 kdhananjay xavih: in the psuedocode, if i make the following modifications, will the end result be the same
09:02 kdhananjay xavih: 1. in afr_writev(), dont create the main txn
09:02 kdhananjay let it only have preop_txn
09:03 kdhananjay xavih: in afr_writev_preop_txn_cbk() as long as it doesnt call afr_txn_commit(preop_txn), i am assuming that the locks are still held by this WRITE request.
09:04 kdhananjay xavih: so it can create a writev txn and nest it without acquiring locks again (because its still held) and wind writev (lines 13-15)
09:04 xavih kdhananjay: the call to commit() is optional. The txn is already finished. If commit/roolback is not explicitly called from the cbk, when the function return, an implicit commit or rollback (depending on the error) can be assumed
09:04 kdhananjay xavih: and in the cbk of write txn afr_writev_op_txn_cbk(), it will skip committing the txn and wind the post-op in lines 23-25
09:05 xavih kdhananjay: nest it where ?
09:05 xavih kdhananjay: the preop_txn is already finished. We need a parent xlator
09:07 xavih kdhananjay: if we create a new txn inside preop_cbk without a parent, most probably we will still have the locks acquired, but that's an assumption
09:07 pranithk1 xavih: in your example do we need explicit commit at line 38?
09:07 pranithk1 xavih: In https://paste.fedoraproject.org/556739/97522914/ I mean
09:07 kdhananjay xavih: yeah why is it an assumption?
09:09 xavih kdhananjay: the assumption is that the implementation won't release the locks until the callback finishes, but this is not required. The operation has already been executed, so we could release the locks. Waiting until the commit seems to simplify the implementation, but it's an implementation detail, not a conceptual thing
09:10 xavih kdhananjay: if the question is if it can be done, then yes, it can be done. But if the question is if it makes sense conceptually, then no, it doesn't make sense to me
09:11 pranithk1 xavih: If we want only one fop to be done we don't need any parent transaction right?
09:11 pranithk1 xavih: because it is just one operation no further operations/parallel operations
09:12 xavih kdhananjay: we are defining a transaction as an atomicity guarantee. We create a transaction for the preop, so it's executed atomically, then we create anothe txn for the op itself to execute it atomically, and finally we create a new txn for the postop, but who guarantees us that all 3 steps are executed atomically whithout anyone interfering ?
09:12 xavih pranithk1: yes, in that case, of course.
09:13 pranithk1 xavih: I think we should name these differently xavih
09:13 xavih pranithk1: the problem here (as I see it) is the execution of 3 independent operations that need to be processed atomically
09:13 xavih pranithk1: why ?
09:14 pranithk1 xavih: The one which makes sure more than one operation should be differentiated with the one which takes care of just one operation?
09:14 xavih pranithk1: how is it different from being created in afr or being created by another xlator ?
09:14 pranithk1 xavih: I mean main_txn and pre_op_txn shouldn't be of same nature?
09:15 xavih pranithk1: they are the same, the only difference is what they are "protecting"
09:15 pranithk1 xavih: hmm...
09:15 xavih pranithk1: main_txn protects the whole writev fop
09:15 xavih pranithk1: preop_txn protects only the xattrop or whatever is executed as preop
09:15 pranithk1 xavih: hmm... got it
09:16 xavih pranithk1: in fact, main_txn is not really required if another xlator has already created a txn
09:16 pranithk1 xavih: yeah I got that part....
09:16 xavih pranithk1: so if it's a transaction from the point of view of another xlator, why should we define it in another way inside afr ?
09:16 pranithk1 xavih: We will do one final diagram here in office and see if we have any doubts kdhananjay and I
09:17 pranithk1 xavih: oh are you saying we will always create main_txn but the library will do the needful?
09:17 pranithk1 xavih: meaning main_txn won't be taking any locks as the parent already created it?
09:17 xavih pranithk1: I don't understand what do you mean...
09:17 pranithk1 xavih: We have the code exactly as in https://paste.fedoraproject.org/556739/97522914/ whether we have parent transaction or not
09:17 xavih pranithk1: oh, I think you are still thinking very low level... this is why you are asking all this...
09:18 pranithk1 xavih: may be :-)
09:18 xavih pranithk1: locks (if txn implementation really used locks, which is not mandatory) are not acquired per transaction
09:19 pranithk1 xavih: yeah
09:19 xavih pranithk1: it's irrelevant how many transactions you create and how many of them are related to one inode. The library will take the apropriate locks when necessary and only once
09:20 pranithk1 xavih: yeah I got it
09:20 kdhananjay joined #gluster-dev
09:20 pranithk1 xavih: so the code can stay as is in both cases if shard xlator starts the transaction or afr...
09:20 xavih pranithk1: you only need to think in terms of atomic operations. Let the details of how this is really implemented for a second round
09:20 pranithk1 xavih: transaction library will take care
09:20 pranithk1 xavih: yeah
09:21 pranithk1 xavih: I think I understood the concept xavih. kdhananjay and I will have a discussion now...
09:21 xavih pranithk1: if we are sure that afr_writev will *always* be called inside a transaction, then there's no need to create main_txn
09:21 xavih pranithk1: because in fact it has already been created by a parent xlator
09:21 xavih pranithk1: the transaction is always needed, but can be created by other xlators
09:22 pranithk1 xavih: yeah... got it
09:27 pranithk1 xavih: this may take a while... if there are some questions kdhananjay asks which I can't explain I will ping you
09:28 xavih pranithk|afk: sorry. I haven't answered your last question... yes, we can use the same code even if shard creates a txn. This will create a new txn, but a txn definition is very light-weight. It does not involve any additional network request. Basically it will make the txn created by shard a simple txn formed by a single sub-txn that will contain 3 other sub-txn.
09:30 xavih pranithk|afk: no problem :)
09:41 pranithk1 xavih: kdhananjay also understood the concept :-). We will try to find the implementation details for this and have second round of interaction. Makes sense?
09:42 pranithk1 xavih: We will just call them parent transaction and child transactions. All of them are same... transactions...
09:42 pranithk1 xavih: okay we will go for lunch now. Thanks for your time xavih
09:42 xavih pranithk1: make sense. However, this is my point of view. I might be wrong. So I want to discuss anything you don't clearly see... :)
09:42 xavih pranithk|afk: you're welcome :)
10:20 nigelb xavih: I found an interesting problem.
10:20 nigelb dispersed volumes still fail.
10:20 nigelb Because /usr/libexec/glusterfs doesn't exist by default.
10:23 percevalbot joined #gluster-dev
10:25 nigelb anoopcs: ^^
10:26 nigelb anoopcs: Do we create /usr/libexec/glusterfs by default?
10:28 anoopcs nigelb, It should be created by default...
10:29 anoopcs during install.
10:29 anoopcs I see glusterfsfind directory inside..
10:30 nigelb anoopcs: should I be looking on servers or clients?
10:31 nigelb ah, it's there on servers.
10:33 nigelb anoopcs: This is the error I see on the client http://dpaste.com/20VH0Y3
10:34 nigelb attempting a fuse mount.
10:34 nigelb so, the question is...is this bit of code supposed to run on the server or client?
10:40 anoopcs nigelb, I need to check the code to confirm what we are missing here.. Did you configure something special before install?
10:41 nigelb Nope.
10:41 anoopcs I mean while running the configure script?
10:41 nigelb no, this is our standard nightly build.
10:41 nigelb I'm checking if this code is executed client side.
10:43 anoopcs nigelb, See its the client which tries to create this particular temp file under /usr/libexec/glusterfs/.
10:43 anoopcs nigelb, Yeah... you are right
10:44 nigelb The problem is we create /usr/libexec/glusterfs/ for the server package.
10:44 anoopcs https://paste.fedoraproject.org/556781/98264914
10:44 * anoopcs is was checking the same thing...
10:44 nigelb I *think* that's what we do.
10:44 anoopcs Oh...God This is a severe issue.
10:44 nigelb I could be wrong.
10:48 nigelb anoopcs: shall I file a follow up bug?
10:48 anoopcs nigelb, Can you please make sure that test passes if we create /usr/libexec/glusterfs/ manually?
10:49 anoopcs nigelb, Yes.. Please file a bug.
10:50 nigelb I'm doing that now.
10:50 nigelb I'll file a bug with results after this test runs.
10:51 nigelb so far it appears that if I install the glusterfs-server package (thereby creating the /usr/libexec/glusterfs/ folder correctly), it seems to work.
10:51 anoopcs Oh... 3.10 also have this patch I guess.
10:51 nigelb Yep, I'll poke Shyam about the bug.
10:52 ankit_ joined #gluster-dev
10:53 nthomas joined #gluster-dev
11:01 ppai joined #gluster-dev
11:11 xavih nigelb, anoopcs: sorry I wasn't here. Can this be solved by updating the client package to create the directory ?
11:12 anoopcs xavih, I think so. Need to check with kkeithley
11:14 anoopcs nigelb, Have you tried every access mechanisms or just FUSE?
11:14 anoopcs after having /usr/libexec/glusterfs in place..
11:16 nigelb anoopcs: I've tried all of the mechanisms with the directory in place.
11:16 nigelb All works.
11:16 nigelb Should I try all of them without the directory as well?
11:16 anoopcs Cool.
11:16 anoopcs nigelb, No...no..It's fine.
11:17 anoopcs We are good.
11:17 nigelb xavih: Most likely. I'm not the packaging expert, so I'll leave that to people who know better than I :)
11:18 xavih nigelb: I don't know how packaging works either :)
11:18 nigelb I'm so sorry I couldn't test the package before today.
11:19 anoopcs xavih, nigelb: I will take care of it.
11:19 nigelb Thank you :)
11:19 anoopcs Since I am also responsible for introducing this problem
11:20 nigelb We all are, in one way or another :)
11:20 xavih anoopcs: thanks :)
11:21 anoopcs np.
11:21 xavih anoopcs: more responsible than I ? :-/
11:21 anoopcs :-)
11:22 humblec joined #gluster-dev
11:35 apandey_ joined #gluster-dev
11:44 atinm joined #gluster-dev
11:51 pranithk|afk anyone, is git pull working for you on gluster repo?
11:54 ChatSharp joined #gluster-dev
11:57 pranithk1 it just worked...
11:57 ChatSharp left #gluster-dev
11:57 atinm joined #gluster-dev
12:28 rajesh joined #gluster-dev
12:32 mchangir joined #gluster-dev
12:35 rraja joined #gluster-dev
12:43 anoopcs kkeithley, https://bugzilla.redhat.com/show_bug.cgi?id=1421649. Is it OK to create %{_libexecdir}/glusterfs as part of client package?
12:43 glusterbot Bug 1421649: unspecified, unspecified, ---, bugs, NEW , When using a fuse mount for client, EC volumes do not mount.
12:47 pranithk1 joined #gluster-dev
12:49 anoopcs ndevos, ^^
12:52 pranithk1 joined #gluster-dev
12:52 xavih joined #gluster-dev
12:56 shyam joined #gluster-dev
13:00 pranithk1 joined #gluster-dev
13:01 ankit_ joined #gluster-dev
13:06 ppai joined #gluster-dev
13:08 gem joined #gluster-dev
13:09 susant left #gluster-dev
13:19 kotreshhr left #gluster-dev
13:31 pmisiak_ joined #gluster-dev
13:31 purpleid1a joined #gluster-dev
13:33 nbalacha joined #gluster-dev
13:34 [o__o] joined #gluster-dev
14:00 ndevos anoopcs: depends on what you need to put in there?
14:01 anoopcs ndevos, https://review.gluster.org/#/c/16612/
14:02 anoopcs ndevos, http://git.gluster.org/cgit/glusterfs.git/tree/xlators/cluster/ec/src/ec-code.c#n398
14:03 anoopcs What's your opinion?
14:03 ankit_ joined #gluster-dev
14:03 jiffin joined #gluster-dev
14:03 ndevos anoopcs: that definitely is wrong, /usr/lib can be read-only and shared over NFS or the like
14:05 anoopcs ndevos, Hm..Ok. Do you have any other location in mind?
14:06 ndevos anoopcs: /var/cache would be better, if the generated code stays around for a while
14:06 jiffin1 joined #gluster-dev
14:07 ndevos anoopcs: maybe it needs specific permissions for the selinux-policy, but that should not be a reason to place it under /usr/lib or /lib
14:09 anoopcs If so.. this is going to be difficult since that particular directory needs to have a executable SELinux labeling..
14:10 anoopcs We need to check whether /var/cache works well or not.
14:11 msvbhat joined #gluster-dev
14:13 ndevos anoopcs: sure, but getting that added to the selinux-policy would be the right thing, we need selinux-policy updates every now and then anyways
14:13 jiffin joined #gluster-dev
14:16 jiffin1 joined #gluster-dev
14:16 ndevos anoopcs: or maybe /run/gluster/lib ?
14:17 ndevos xavih: how long can the generated ec code-files live? would they persist a reboot?
14:18 ndevos anoopcs: depending on ^, (/var)/run would be better, it is cleaned upon boot
14:19 anoopcs ndevos, I see this http://git.gluster.org/cgit/glusterfs.git/tree/xlators/cluster/ec/src/ec-code.c#n432 in the same function.
14:20 anoopcs EC uses it as a backend file for mmap.
14:21 mchangir joined #gluster-dev
14:22 ndevos anoopcs: right, then /var/run/gluster/lib is definitely much better
14:24 ndevos anoopcs: /run/gluster is already created through a tmpfiles.d snippet, the /lib addition can be added there and even have suitable selinux context set
14:25 anoopcs ndevos, Do we really set selinux context in glusterfs spec file/
14:26 ndevos anoopcs: no, not in the .spec, but in http://git.gluster.org/cgit/glusterfs.git/tree/extras/run-gluster.tmpfiles.in you can do it
14:28 anoopcs ndevos, How does that really work? This is the first time I am seeing it..
14:28 * anoopcs checking the Makefile.am...
14:30 ndevos anoopcs: /run/gluster is created on boot through that config file, you can add a new line with the /lib directory there and set a security.selinux xattr (see 'man tmpfiles.d')
14:36 anoopcs ndevos, It's new to me. I will have to test it out.
14:36 ndevos anoopcs: hmm, probably still need a selinux-policy update for CentOS-6, it might not use tmpfiles? (and setting the context in tmpfiles is a workaround in any case)
14:39 anoopcs ndevos, So how does it reload?
14:39 anoopcs I mean the new SELinux context?
14:44 ndevos anoopcs: there is a systemd-tmpfiles (or something) service that reads the tmpfiles
14:44 ndevos anoopcs: and the manual page shows how to set custom xattrs, that ways you can set the security.selinux one to something usable
14:45 anoopcs ndevos, Yeah.. It's 't'
14:46 ndevos anoopcs: btw, this will give us some troubles when gfapi processes are not running as root :-(
14:58 skoduri joined #gluster-dev
15:24 gyadav_ joined #gluster-dev
15:27 jiffin joined #gluster-dev
15:44 ankit_ joined #gluster-dev
15:50 lpabon joined #gluster-dev
16:02 ankit_ joined #gluster-dev
16:02 Shu6h3ndu joined #gluster-dev
16:05 wushudoin joined #gluster-dev
16:10 ankit_ joined #gluster-dev
16:24 shaunm joined #gluster-dev
16:58 lpabon_ joined #gluster-dev
16:59 lpabon joined #gluster-dev
17:02 lpabon joined #gluster-dev
17:15 rafi joined #gluster-dev
19:54 msvbhat joined #gluster-dev
21:55 k4n0 joined #gluster-dev
22:20 gem joined #gluster-dev
22:22 gem joined #gluster-dev

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