Camelia, the Perl 6 bug

IRC log for #gluster-dev, 2012-10-26

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

All times shown according to UTC.

Time Nick Message
00:03 badone joined #gluster-dev
00:15 bfoster joined #gluster-dev
00:16 jdarcy_ joined #gluster-dev
00:16 kkeithley1 joined #gluster-dev
00:40 bala1 joined #gluster-dev
02:15 sunus joined #gluster-dev
02:44 sunus joined #gluster-dev
03:22 bharata joined #gluster-dev
04:00 sripathi joined #gluster-dev
04:02 bulde1 joined #gluster-dev
04:29 sripathi1 joined #gluster-dev
04:31 bulde1 joined #gluster-dev
04:32 deepakcs joined #gluster-dev
05:32 puebele joined #gluster-dev
05:52 badone joined #gluster-dev
06:39 lkoranda joined #gluster-dev
06:41 sripathi joined #gluster-dev
06:44 lkoranda joined #gluster-dev
06:59 sripathi joined #gluster-dev
08:22 kd joined #gluster-dev
08:23 kd left #gluster-dev
08:51 deepakcs joined #gluster-dev
08:58 sripathi1 joined #gluster-dev
11:27 bala joined #gluster-dev
11:41 dobber joined #gluster-dev
11:57 sripathi joined #gluster-dev
12:08 edward1 joined #gluster-dev
12:56 13WABPA6E joined #gluster-dev
12:57 mdarade1 left #gluster-dev
13:16 puebele1 joined #gluster-dev
14:02 sghosh joined #gluster-dev
14:17 wushudoin joined #gluster-dev
14:19 foster jdarcy_: any reason you can think of to not bubble up errors (not associated with disconnect, such as ENOTCONN) and short writes in afr_writev_wind_cbk()?
14:38 sghosh joined #gluster-dev
14:57 sghosh joined #gluster-dev
15:08 jdarcy_ foster: I suppose there might be some issues around. the case where we fail on one replica and still succeed on another
15:09 foster jdarcy: by that, do you mean the enotconn case?
15:10 foster (that's what I hit by instrumenting a down glusterfsd situation when afr is about to wind a write)
15:10 jdarcy For any error, really. What if we get OK/EINVAL?
15:11 foster then isn't that a write error, and should be returned?
15:12 foster this is re bug 853690 btw, which has more context
15:12 jdarcy I could see users arguing either side of that.
15:17 foster I suppose I can see an argument for operation error resiliency, but it seems there's still opportunity for errors we won't return or recover from...
15:17 foster a short write situation for instance
15:18 foster in the case of an explicit error from a child, does afr do something to ensure that the file with the non-error is preferred?
15:18 jdarcy Seems like ENOSPC specifically should bubble up.
15:19 jdarcy I don't think we have enough error state to choose a non-erroring replica.
15:20 foster ok
15:20 jdarcy Maybe that's the real bug
15:21 jdarcy Are you in 314 today?
15:21 foster no, I'm wfh today
15:22 foster Hmm, I would think a user would want to see an ENOSPC, EIO, maybe others, regardless
15:24 foster the change I was going to propose is to bubble up any not-ENOTCONN writev error
15:24 jdarcy If we fail the request but did in fact overwrite data, how do we recover?
15:26 foster by recover, do you mean "undo?"
15:26 jdarcy Basically.
15:27 foster I'm not really following why we would need to.
15:28 foster (assuming the user sees an error)
15:29 jdarcy One replica had an error, the other overwrote data. Which one is authoritative, and how do we bring them back in sync?
15:30 * jdarcy is typing on a phone, BTW. Slow.
15:30 foster heh, np
15:30 foster your write failed. why is it the replicas responsibility to sync?
15:31 jdarcy Because it actually did happen at one or more replicas.
15:32 foster so a failed write means, for example, a read should guarantee to return old data?
15:32 jdarcy The error got us out of sync.
15:33 jdarcy Right. Persistent divergence between replicas is a major failure.
15:33 foster Ok, I see...
15:34 foster but the point there is not that we shouldn't return error, but that the erroneous copy should be marked bad one way or another..?
15:36 jdarcy That would be OK too. Maybe outcast?
15:37 foster I'll have to familiarize myself with the consistency states
15:37 jdarcy What if we get ENOSPC on the setxattr?
15:40 foster not sure. isn't that a concern regardless (i.e., don't all afr fops that make modifications push some state via setxattr)?
15:40 foster perhaps the brick runs out of space for the first time on a setxattr
15:40 jdarcy Yes, we probably have that problem already.
15:41 foster I'll have to think about this some more...
15:42 foster What about the short write situation? Typically a client should retry the remainder of the write...
15:42 jdarcy Quite a can of worms, huh?
15:42 foster but I suppose we need to think about what happens if the client doesn't
15:42 foster heh
15:42 foster indeed
15:51 bala joined #gluster-dev
16:35 hagarth joined #gluster-dev
19:06 jbrooks joined #gluster-dev
22:57 edward1 joined #gluster-dev

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