#ceph IRC Log

Index

IRC Log for 2012-06-29

Timestamps are in GMT/BST.

[0:08] * s[X] (~sX]@eth589.qld.adsl.internode.on.net) has joined #ceph
[0:35] * BManojlovic (~steki@212.200.241.3) Quit (Quit: Ja odoh a vi sta 'ocete...)
[0:40] * gregorg_taf (~Greg@78.155.152.6) has joined #ceph
[0:40] * gregorg (~Greg@78.155.152.6) Quit (Read error: Connection reset by peer)
[0:51] <joshd> nhm: here
[1:01] * sjustlaptop (~sam@aon.hq.newdream.net) Quit (Ping timeout: 480 seconds)
[1:05] * yehudasa_ (~yehudasa@aon.hq.newdream.net) Quit (Ping timeout: 480 seconds)
[1:18] * lxo (~aoliva@lxo.user.oftc.net) Quit (Quit: later)
[1:19] * andreask (~andreas@chello062178013131.5.11.vie.surfer.at) Quit (Quit: Leaving.)
[1:20] * baobrien (~baobrien@76.77.236.0) Quit (Read error: Connection reset by peer)
[1:29] * lxo (~aoliva@lxo.user.oftc.net) has joined #ceph
[1:42] * JT (~john@astound-64-85-227-32.ca.astound.net) Quit (Remote host closed the connection)
[2:06] * Tv_ (~tv@aon.hq.newdream.net) Quit (Quit: Tv_)
[2:06] * adjohn (~adjohn@50-0-133-101.dsl.static.sonic.net) Quit (Quit: adjohn)
[2:08] * chutzpah (~chutz@216.174.109.254) Quit (Quit: Leaving)
[2:13] * sjustlaptop (~sam@aon.hq.newdream.net) has joined #ceph
[2:16] * adjohn (~adjohn@50-0-133-101.dsl.static.sonic.net) has joined #ceph
[2:25] * brambles (brambles@79.133.200.49) Quit (Quit: leaving)
[2:25] * brambles (brambles@79.133.200.49) has joined #ceph
[2:29] * sjustlaptop (~sam@aon.hq.newdream.net) Quit (Ping timeout: 480 seconds)
[2:30] * mdxi_ (~mdxi@74-95-29-182-Atlanta.hfc.comcastbusiness.net) has joined #ceph
[2:30] * mdxi (~mdxi@74-95-29-182-Atlanta.hfc.comcastbusiness.net) Quit (Read error: Connection reset by peer)
[2:34] * aliguori (~anthony@cpe-70-123-145-39.austin.res.rr.com) Quit (Remote host closed the connection)
[3:12] * lurbs (user@uber.geek.nz) has joined #ceph
[3:14] <lurbs> Is there any further magic required after a "ceph mon tell \* injectargs '--mon-osd-full-ratio 98'" in order to get a cluster writeable again?
[3:17] <joshd> lurbs: I think that should do it
[3:18] <joshd> you could also add a new osd with more space temporarily, and remove it after you've deleted some data
[3:21] <lurbs> As did I, but it doesn't seem to be changing the actual level:
[3:21] <lurbs> http://paste.nothing.net.nz/72da82
[3:22] <lurbs> This is ceph 0.47.3-1precise, BTW.
[3:23] <lurbs> It's just a test cluster, so I could trash the entire thing and start again, but it'd be nice to be able to recover cleanly as a test for if it makes it into production.
[3:39] <joshd> lurbs: try 'ceph pg set_full_ratio 98'
[3:39] <joshd> I don't see mon_osd_full_ratio being used after the initial map creation
[3:43] <lurbs> *Something* that I did cleared it up, it's now reporting near full. Will go back through logs to see what it was.
[3:43] <lurbs> Thanks. :)
[3:48] <lurbs> http://paste.nothing.net.nz/72da82
[3:48] <lurbs> Looks like it wants a float, not a percentage.
[3:49] <lurbs> It was 'rados bench ... write' that filled it BTW.
[3:54] <joshd> yeah, you're right, set_full_ratio takes a float
[3:54] <joshd> you can see the current values at the top of 'ceph pg dump'
[4:01] <lurbs> http://paste.nothing.net.nz/c90af8
[4:01] <lurbs> Looking much happier now.
[4:04] <joshd> excellent
[4:10] * joshd (~joshd@aon.hq.newdream.net) Quit (Quit: Leaving.)
[4:12] * sjustlaptop (~sam@24-205-39-1.dhcp.gldl.ca.charter.com) has joined #ceph
[4:13] * Ryan_Lane1 (~Adium@dslb-188-106-098-018.pools.arcor-ip.net) has joined #ceph
[4:19] * Ryan_Lane (~Adium@dslb-094-223-090-139.pools.arcor-ip.net) Quit (Ping timeout: 480 seconds)
[5:33] * adjohn (~adjohn@50-0-133-101.dsl.static.sonic.net) Quit (Quit: adjohn)
[5:34] * adjohn (~adjohn@50-0-133-101.dsl.static.sonic.net) has joined #ceph
[5:34] * adjohn (~adjohn@50-0-133-101.dsl.static.sonic.net) Quit ()
[5:35] * gregaf1 (~Adium@aon.hq.newdream.net) has joined #ceph
[5:39] * gregaf (~Adium@aon.hq.newdream.net) Quit (Ping timeout: 480 seconds)
[5:42] * cattelan is now known as cattelan_away
[5:47] * izdubar (~MT@c-71-198-138-155.hsd1.ca.comcast.net) has joined #ceph
[5:54] * MarkDude (~MT@c-71-198-138-155.hsd1.ca.comcast.net) Quit (Ping timeout: 480 seconds)
[6:02] * dmick (~dmick@aon.hq.newdream.net) Quit (Quit: Leaving.)
[6:31] * Ryan_Lane (~Adium@dslb-188-106-098-018.pools.arcor-ip.net) has joined #ceph
[6:31] * Ryan_Lane1 (~Adium@dslb-188-106-098-018.pools.arcor-ip.net) Quit (Read error: Connection reset by peer)
[6:32] * fghaas (~florian@91.119.87.169) has joined #ceph
[6:48] * fghaas (~florian@91.119.87.169) Quit (Ping timeout: 480 seconds)
[7:00] -kinetic.oftc.net- *** Looking up your hostname...
[7:00] -kinetic.oftc.net- *** Checking Ident
[7:00] -kinetic.oftc.net- *** No Ident response
[7:00] -kinetic.oftc.net- *** Found your hostname
[7:00] * CephLogBot (~PircBot@rockbox.widodh.nl) has joined #ceph
[7:18] * The_Bishop (~bishop@2a01:198:2ee:0:706f:bd55:8efa:c494) Quit (Quit: Wer zum Teufel ist dieser Peer? Wenn ich den erwische dann werde ich ihm mal die Verbindung resetten!)
[7:31] * fghaas (~florian@91.119.87.169) has joined #ceph
[7:39] * sjustlaptop (~sam@24-205-39-1.dhcp.gldl.ca.charter.com) Quit (Ping timeout: 480 seconds)
[7:57] * Ryan_Lane1 (~Adium@dslb-188-106-098-018.pools.arcor-ip.net) has joined #ceph
[7:57] * Ryan_Lane (~Adium@dslb-188-106-098-018.pools.arcor-ip.net) Quit (Read error: Connection reset by peer)
[8:01] * loicd (~loic@magenta.dachary.org) has joined #ceph
[8:04] * JT (~john@astound-64-85-227-32.ca.astound.net) has joined #ceph
[8:08] * JT (~john@astound-64-85-227-32.ca.astound.net) Quit ()
[8:13] * loicd (~loic@magenta.dachary.org) Quit (Quit: Leaving.)
[8:13] * joao (~JL@89.181.154.67) has joined #ceph
[8:19] * jluis (~JL@89.181.149.17) Quit (Ping timeout: 480 seconds)
[9:13] * s[X] (~sX]@eth589.qld.adsl.internode.on.net) Quit (Remote host closed the connection)
[9:14] * BManojlovic (~steki@91.195.39.5) has joined #ceph
[9:15] * loicd (~loic@83.167.43.235) has joined #ceph
[9:28] * goedi (goedi@195.26.5.166) Quit (Ping timeout: 480 seconds)
[9:36] * goedi (goedi@195.26.5.166) has joined #ceph
[9:46] * andreask (~andreas@chello062178013131.5.11.vie.surfer.at) has joined #ceph
[10:24] * nolan (~nolan@2001:470:1:41:20c:29ff:fe9a:60be) Quit (Quit: ZNC - http://znc.sourceforge.net)
[10:26] * nolan (~nolan@2001:470:1:41:20c:29ff:fe9a:60be) has joined #ceph
[11:08] <fghaas> anyone currently here who's aware of the config option to tweak the minimum interval in which mon leaders increment the osd map epoch?
[11:11] <joao> the osdmap epoch is incremented each time the osdmap suffers any kind of change
[11:13] <joao> to the best of my knowledge, there is no interval involved
[11:13] <joao> not in the sense you are describing at least
[11:13] <fghaas> one of sage's papers says that the mon leader may wait for several such changes, aggregate them, and only update the map periodically. looks like that functionality was never implemented, or dropped
[11:14] <joao> no, that may still happen
[11:14] <joao> we do backoff the proposal if we proposed recently
[11:14] <joao> but that's not specific to the osdmap
[11:15] <joao> there is a paxos_propose_interval option
[11:15] <fghaas> I guess that's what I was looking for :)
[11:15] * izdubar (~MT@c-71-198-138-155.hsd1.ca.comcast.net) Quit (Ping timeout: 480 seconds)
[11:15] <joao> but I must say, the osdmap monitor takes some liberties to when it comes to propose pending changes
[11:17] <joao> for instance, adjusting osd weights will completely ignore that config option
[11:18] <fghaas> yeah, I guess it makes complete sense to override that for an actual admin intervention
[11:18] <fghaas> rather than a report of a random failure
[11:21] * joao (~JL@89.181.154.67) Quit (Quit: Leaving)
[11:21] * joao (~JL@89-181-154-67.net.novis.pt) has joined #ceph
[11:23] <fghaas> joao: also (semi-related), is there any documentation on *how* a mon leader is elected? iow, among available mons, what influences any mon's chances of winning the election?
[11:23] <joao> it's based on their rank; and their rank (iirc) is based on their name
[11:23] <joao> or its port
[11:24] <joao> give me a couple of seconds and I'll confirm it
[11:28] <joao> yeah, I'm pretty sure it's by name
[11:28] <fghaas> yeah, looks like it
[11:29] <fghaas> well, actually mine are named alphabetically, and listen on incrementing ip addresses, bound to incrementing map addresses :)
[11:29] <fghaas> but I'll take your word for it
[11:30] <fghaas> well, actually
[11:30] <fghaas> int newrank = monmap->get_rank(messenger->get_myaddr());
[11:31] <fghaas> so, address after all?
[11:31] <joao> yeah, I've been looking at it
[11:31] <joao> it does associate the name of the mon, but it traverses the map ordered by address
[11:31] * plastics (~plastics@c-69-138-42-222.hsd1.tn.comcast.net) has joined #ceph
[11:32] <fghaas> ok, thanks joao :)
[11:34] <joao> fghaas, if you are really interested, you should look into mon/MonMap.h and look for MonMap::calc_ranks()
[11:39] * plastics (~plastics@c-69-138-42-222.hsd1.tn.comcast.net) Quit (Ping timeout: 480 seconds)
[11:40] * fghaas (~florian@91.119.87.169) Quit (Ping timeout: 480 seconds)
[11:53] <joao> great
[11:53] <joao> with all this messing around with mon names and ranks, I just triggered an assert
[12:46] * alexxy (~alexxy@2001:470:1f14:106::2) has joined #ceph
[13:23] * s[X] (~sX]@ppp59-167-157-96.static.internode.on.net) has joined #ceph
[13:24] * loicd (~loic@83.167.43.235) Quit (Quit: Leaving.)
[13:25] * loicd (~loic@83.167.43.235) has joined #ceph
[13:29] * loicd (~loic@83.167.43.235) Quit ()
[13:48] * goedi (goedi@195.26.5.166) Quit (Ping timeout: 480 seconds)
[13:48] * goedi (goedi@195.26.5.166) has joined #ceph
[13:51] * goedi (goedi@195.26.5.166) Quit (Remote host closed the connection)
[13:52] * goedi (goedi@195.26.5.166) has joined #ceph
[14:11] * nhorman (~nhorman@hmsreliant.think-freely.org) has joined #ceph
[14:23] * loicd (~loic@APuteaux-651-1-82-117.w81-249.abo.wanadoo.fr) has joined #ceph
[14:26] * aliguori (~anthony@cpe-70-123-145-39.austin.res.rr.com) has joined #ceph
[14:35] * plastics (~plastics@c-69-138-42-222.hsd1.tn.comcast.net) has joined #ceph
[14:37] * gregorg_taf (~Greg@78.155.152.6) Quit (Read error: Connection reset by peer)
[14:38] * gregorg (~Greg@78.155.152.6) has joined #ceph
[14:41] * joao (~JL@89-181-154-67.net.novis.pt) Quit (Quit: Leaving)
[14:50] * joao (~JL@89-181-154-67.net.novis.pt) has joined #ceph
[15:18] * plastics- (~plastics@c-69-138-42-222.hsd1.tn.comcast.net) has joined #ceph
[15:20] * plastics (~plastics@c-69-138-42-222.hsd1.tn.comcast.net) Quit (Ping timeout: 480 seconds)
[15:29] * cattelan_away is now known as cattelan
[15:40] * oliver (~oliver@jump.filoo.de) has joined #ceph
[15:58] * loicd (~loic@APuteaux-651-1-82-117.w81-249.abo.wanadoo.fr) Quit (Quit: Leaving.)
[16:33] * BManojlovic (~steki@91.195.39.5) Quit (Quit: Ja odoh a vi sta 'ocete...)
[16:34] * BManojlovic (~steki@91.195.39.5) has joined #ceph
[16:37] * loicd (~loic@83.167.43.235) has joined #ceph
[16:40] * sjustlaptop (~sam@24-205-39-1.dhcp.gldl.ca.charter.com) has joined #ceph
[16:48] * BManojlovic (~steki@91.195.39.5) Quit (Quit: Ja odoh a vi sta 'ocete...)
[16:48] * BManojlovic (~steki@91.195.39.5) has joined #ceph
[16:55] * s[X] (~sX]@ppp59-167-157-96.static.internode.on.net) Quit (Remote host closed the connection)
[17:07] * oliver (~oliver@jump.filoo.de) has left #ceph
[17:13] * BManojlovic (~steki@91.195.39.5) Quit (Quit: Ja odoh a vi sta 'ocete...)
[17:37] * plastics- (~plastics@c-69-138-42-222.hsd1.tn.comcast.net) Quit (Ping timeout: 480 seconds)
[17:44] * sjustlaptop (~sam@24-205-39-1.dhcp.gldl.ca.charter.com) Quit (Ping timeout: 480 seconds)
[17:46] * plastics (~plastics@c-69-138-42-222.hsd1.tn.comcast.net) has joined #ceph
[17:54] * andreask (~andreas@chello062178013131.5.11.vie.surfer.at) Quit (Ping timeout: 480 seconds)
[17:55] * sagelap1 (~sage@228.sub-166-250-64.myvzw.com) has joined #ceph
[17:58] * loicd (~loic@83.167.43.235) Quit (Quit: Leaving.)
[18:00] * sagelap1 (~sage@228.sub-166-250-64.myvzw.com) has left #ceph
[18:00] * sagelap1 (~sage@228.sub-166-250-64.myvzw.com) has joined #ceph
[18:10] * bchrisman (~Adium@c-76-103-130-94.hsd1.ca.comcast.net) Quit (Quit: Leaving.)
[18:11] * Tv_ (~tv@aon.hq.newdream.net) has joined #ceph
[18:21] * JT (~john@astound-64-85-227-32.ca.astound.net) has joined #ceph
[18:37] * fghaas (~florian@91.119.51.139) has joined #ceph
[18:41] * sagelap1 (~sage@228.sub-166-250-64.myvzw.com) Quit (Remote host closed the connection)
[18:52] * fghaas (~florian@91.119.51.139) Quit (Ping timeout: 480 seconds)
[19:00] * joshd (~joshd@aon.hq.newdream.net) has joined #ceph
[19:01] <elder> joshd, I have a question for you. Mostly just curious.
[19:01] <joshd> ask away
[19:01] <elder> What is the purpose of the one-byte initial value in an encoded filepath?
[19:02] <joshd> where are you looking?
[19:03] <elder> include/linux/ceph/decode.h in ceph-client.
[19:03] <elder> ceph_encode_filepath()
[19:03] <elder> Encodes a single byte 1
[19:03] <elder> Then the inode, then the length. Is it interpreted as a set of one pair>?
[19:03] <elder> (inode, path) pair?
[19:04] <elder> (no, it's a one-byte count)
[19:05] * chutzpah (~chutz@100.42.98.5) has joined #ceph
[19:05] <joshd> I do not know, but I don't see any mention of filepath in the userspace encoding... maybe it's unused?
[19:05] <elder> Could be. I was fixing a bug in the function--in that it doesn't account for that extra byte.
[19:06] <elder> But I didn't know what that byte was for. Does the server side include it when it's en/decoding a filepath?
[19:06] <joshd> nevermind, I found it
[19:06] <joshd> it's a struct version number
[19:06] <elder> OK, that was my other theory.
[19:06] <elder> Not very well documented...
[19:07] <gregaf1> as opposed to anything else?
[19:07] <gregaf1> that's a new idiom for all our structs starting???two years ago?
[19:07] <elder> What, don't document?
[19:07] <gregaf1> the struct_v version at the front
[19:08] <elder> OK, I'll know what to expect now if I encounter that in the future.
[19:08] <elder> In that case, joshd, the lockers field, which is apparently a set of pairs of strings, maybe ought to include a one-byte struct_v...
[19:09] <elder> In get_mutable_metadata()
[19:11] <elder> (Depending on how serious we are about versioning over-the-wire structured data.)
[19:12] <joshd> we could add a version number to each method and it's return, but I think it's simpler to have new methods if we need to change their return values or arguments
[19:12] <gregaf1> the lockers field is literally an encoded set of string pairs or something, right? that isn't going to change its encoding
[19:13] <gregaf1> but if we forgot to include struct_v values on some collection of aggregate values, we screwed up
[19:14] <elder> So if there becomes a new immutable bit of metadata, we define a new get_immutable_metadata_1() method?
[19:14] <joshd> remember get_immutable_metadata is on the client side
[19:15] <joshd> it would just be calling more class methods if we added more immutable metadata
[19:15] <elder> Well, I thought the name suggested that it was a collecting point for all immutable metadata for an rbd.
[19:15] <elder> image
[19:16] <joshd> yes, it is, but it's a client-side function - it doesn't have an over-the-wire protocol of its own
[19:16] <elder> But it has to interpret what comes back.
[19:17] * bchrisman (~Adium@108.60.121.114) has joined #ceph
[19:17] <joshd> yes, and those encodings won't change
[19:19] * fghaas (~florian@91.119.51.139) has joined #ceph
[19:21] * sjustlaptop (~sam@aon.hq.newdream.net) has joined #ceph
[19:24] * plastics- (~plastics@c-69-138-42-222.hsd1.tn.comcast.net) has joined #ceph
[19:28] * plastics (~plastics@c-69-138-42-222.hsd1.tn.comcast.net) Quit (Ping timeout: 480 seconds)
[19:28] * dmick (~dmick@aon.hq.newdream.net) has joined #ceph
[19:34] * Ryan_Lane (~Adium@dslb-188-106-098-018.pools.arcor-ip.net) has joined #ceph
[19:34] * Ryan_Lane1 (~Adium@dslb-188-106-098-018.pools.arcor-ip.net) Quit (Read error: Connection reset by peer)
[19:42] <joao> sjust, around?
[19:43] <sjustlaptop> yep
[19:43] <joao> say we get an iterator from the LevelDBStore, with an empty prefix; should it then return an iterator that will iterate over all the keys in the store, prefix-independently?
[19:44] <joao> or should we know about each prefix in order to make it work?
[19:44] <joao> *each existing prefix
[19:44] <sjustlaptop> no
[19:44] <sjustlaptop> it will stop iterating at the end of the specified prefix
[19:45] <joao> say we have 5 different prefixes in the store
[19:45] <joao> does that mean 5 different iterators, with different prefixes?
[19:45] <sjustlaptop> yes
[19:46] <fghaas> could one of you guys point me to examples/references for the libradospp c++ api? http://ceph.com/docs/master/api/libradospp/ isn't exactly exhaustive :)
[19:47] <joshd> fghaas: see https://github.com/ceph/ceph/tree/master/src/test/rados-api
[19:47] <joao> sjustlaptop, thanks
[19:47] <joshd> fghaas: it's mostly the same as the C api, which is documented in librados.h
[19:48] <fghaas> joshd: rockin'
[19:48] <fghaas> thanks
[19:48] <joshd> np
[19:48] <gregaf1> sjust: can't we just provide an empty prefix to get everything? or is that invalid?
[19:49] <sjustlaptop> gregaf1: it's not the best name in the world, it's really a namespace
[19:49] <gregaf1> I admit I'm totally doing helicopter documentation peeks here
[19:50] <gregaf1> but it *looks* like it's possible
[19:50] <gregaf1> well that's annoying
[19:50] <sjustlaptop> it was intended to allow iteration without forcing the iterface user to seperate different groups of keys
[19:50] <sjustlaptop> shoulda called it a namespace though
[19:51] <gregaf1> oh, so this is something you did, not LevelDB?
[19:51] <sjustlaptop> yeah
[19:51] <joshd> which api are you talking about?
[19:51] <sjustlaptop> KeyValueDB
[19:51] <gregaf1> *smack*
[19:51] <gregaf1> :p
[19:52] <dmick> don't make me turn this car around boys
[19:56] <joshd> that doesn't leak into the omap api, does it?
[19:57] <fghaas> gregaf1: at the risk of asking another stupid naive question -- you've previously explained to people on the ML that MONs often do sync() (or syncfs() where available), but I'm not entirely sure _why_ they do that (as opposed to opening individual fd's with O_SYNC or O_DIRECT, for example). mind explaining?
[19:57] <gregaf1> joshd: no, of course not
[19:58] <gregaf1> fghaas: I think they more often do fsync(), but sometimes they have to bundle up a lot of operations all at once so they do sync and/or syncfs()
[19:59] <gregaf1> I may have overstated how much time they spend doing syncs; I'd have to check
[20:00] <fghaas> not sure you overstated, all you said was they do "a lot of syncs" (http://www.spinics.net/lists/ceph-devel/msg06052.html), which leaves some room for interpretation
[20:01] * MarkDude (~MT@c-71-198-138-155.hsd1.ca.comcast.net) has joined #ceph
[20:02] <fghaas> I think the underlying issue was really whether it made sense to run mons on the same disk/fs as osds, and your explanation quite lucidly suggested that it didn't, and why
[20:03] <gregaf1> hmm, yeah, I was at that time incorrect about how many actual syncs it does
[20:04] <gregaf1> which means that the syncfs thing isn't so important
[20:04] <gregaf1> but they do a ton of fsyncs, and adding even more of those to your OSD would suck
[20:04] <gregaf1> (the OSD does more sync() calls than the monitor, which would certainly impact the monitor's performance, but there we just don't care because the monitor's out-of-band and everything anyway)
[20:07] <fghaas> yeah. do the mons/osds ever do things like FLUSH/FUA, where you wait until you've actually hit spinning rust, rather than a potentially available controller cache?
[20:07] <fghaas> not sure if that's even applicable as you're dealing with a local fs as opposed to a block dev; just figured it doesn't hurt to ask
[20:10] <gregaf1> I believe the OSDs do careful flushes as a matter of course; the monitor doesn't get that complicated because it's not so concerned about the throughput
[20:10] <gregaf1> sjust would know
[20:11] <sjustlaptop> we use directio in the journal and syncfs on the store in order to achieve some form of durability
[20:13] <gregaf1> doesn't it sometimes use flushes though, or are those higher-level constructs in our case?
[20:13] <fghaas> yep, but neither directio nor syncfs normally cause the underlying fs to do blkdev_issue_flush or whatever it's called, do they?
[20:15] <gregaf1> I'm not sure, that's why I'm asking Sam ;)
[20:23] <fghaas> ok, I'll bbiab, but feel free to share your insights here and I'll check the log later
[20:23] * fghaas (~florian@91.119.51.139) has left #ceph
[20:29] * plastics- (~plastics@c-69-138-42-222.hsd1.tn.comcast.net) Quit (Ping timeout: 480 seconds)
[20:29] * sjustlaptop (~sam@aon.hq.newdream.net) Quit (Ping timeout: 480 seconds)
[20:36] * sjustlaptop (~sam@aon.hq.newdream.net) has joined #ceph
[20:49] * fghaas (~florian@91.119.51.139) has joined #ceph
[20:50] * BManojlovic (~steki@212.200.241.3) has joined #ceph
[20:51] * sjustlaptop (~sam@aon.hq.newdream.net) Quit (Ping timeout: 480 seconds)
[20:59] * sjustlaptop (~sam@aon.hq.newdream.net) has joined #ceph
[21:14] * sjustlaptop (~sam@aon.hq.newdream.net) Quit (Ping timeout: 480 seconds)
[21:14] <joao> sagewk, gregaf1, hit an assert on master trying to reproduce that assumed-to-be-bug on my branch
[21:19] * steki-BLAH (~steki@212.200.241.3) has joined #ceph
[21:19] <dmick> they're eating lunch ATM joao
[21:19] <joao> thanks :)
[21:22] * BManojlovic (~steki@212.200.241.3) Quit (Ping timeout: 480 seconds)
[21:23] <sagewk> joao: can you pastebin it?
[21:23] <joao> http://pastebin.com/1NWW5dH6
[21:23] <joao> been trying to reproduce it, and failing miserably
[21:26] <dmick> sagewk, Tv_: are you aware of any impending maintenance on sepia? (cf. emerging list discussion)
[21:27] * steki-BLAH (~steki@212.200.241.3) Quit (Ping timeout: 480 seconds)
[21:29] <nhm> dmick: few seconds of downtime: famous last words. :)
[21:30] <joao> btw, sagewk, gregaf1, changed that bug I created earlier today from new to rejected, and to 'feedback' now. Apparently, what I was initially attempting does work on master.
[21:33] <sagewk> joao: that's 2646 (or wahtever), working on it now
[21:33] <sagewk> dmick: not sure... :/
[21:37] * Ryan_Lane1 (~Adium@dslb-188-106-098-018.pools.arcor-ip.net) has joined #ceph
[21:37] * Ryan_Lane (~Adium@dslb-188-106-098-018.pools.arcor-ip.net) Quit (Read error: Connection reset by peer)
[21:45] <joao> sagewk, good to know it is known and not just found :)
[21:49] <Tv_> dmick: it sounds like they're talking about the switch upstream from our 4948...?
[21:49] <Tv_> dmick: but i can't tell
[21:51] <dmick> if they haven't contacted any of the three of us, I'm a little annoyed, I think
[21:52] <nhm> dmick: network disruptions should definitely be communicated.
[21:52] * loicd (~loic@2a01:e35:2eba:db10:120b:a9ff:feb7:cce0) has joined #ceph
[21:54] <nhm> dmick: although I suppose technically the mentioned it on emerge.
[21:54] <dmick> in passing, without detail..
[21:55] * adjohn (~adjohn@50-0-133-101.dsl.static.sonic.net) has joined #ceph
[21:56] * fghaas (~florian@91.119.51.139) Quit (Quit: Leaving.)
[22:02] <elder> sagewk, I have to do a little more work to the existing interfaces (like rbd_req_sync_exec()) than I thought so I won't have something ready as soon as I thought.
[22:03] <elder> sagewk, I will probably push my branch anyway, in part to get it backed up, but don't formally review it until I say it's ready. It will be "wip-rbd-new".
[22:03] * lofejndif (~lsqavnbok@9YYAAHP3B.tor-irc.dnsbl.oftc.net) has joined #ceph
[22:03] <elder> In the mean time you'll see what I'm up to.
[22:25] * JT (~john@astound-64-85-227-32.ca.astound.net) Quit (Quit: Leaving)
[22:25] * nhorman (~nhorman@hmsreliant.think-freely.org) Quit (Quit: Leaving)
[22:32] * ARTi (~austin@24-207-116-28.eastlink.ca) has joined #ceph
[22:33] <sagewk> elder: sounds good
[22:35] <ARTi> quick question, if anyone is around.. I am wondering what the minimum number of servers required for a ceph cluster is. Looking at the docs I see that it requires 3 x mon servers. Are there any other requirements, Im missing? If 3 is the minimum, would it be advisable to start our ceph cluster with 3 servers each with 20+ disks? Expanding as we can, of course.
[22:38] * Cube (~Cube@12.248.40.138) has joined #ceph
[22:43] <gregaf1> ARTi: you can run all the daemons on one machine if you like, you just obviously won't get much redundancy
[22:44] <gregaf1> it's just a poor idea to run an even number of monitors, because that cluster needs a strict majority to get work done, and if you have two mons you will still stop making progress after one failure (same as if one mon dies)
[22:52] * sjustlaptop (~sam@aon.hq.newdream.net) has joined #ceph
[22:53] <dmick> ARTi: I've been testing all week on a single-machine cluster that is also my desktop and build machine
[23:01] <sjustlaptop> fghaas: I thought they did
[23:04] <ARTi> ok
[23:05] <ARTi> are there recommendations to get proper redundancy?
[23:06] * lxo (~aoliva@lxo.user.oftc.net) Quit (Ping timeout: 480 seconds)
[23:08] <ARTi> 3 servers. with a copy required on each server
[23:09] * sjustlaptop (~sam@aon.hq.newdream.net) Quit (Ping timeout: 480 seconds)
[23:12] <gregaf1> if you set it to do 3 replication, and you fill in the host fields appropriately for each OSD, it will do what you want
[23:14] * lxo (~aoliva@lxo.user.oftc.net) has joined #ceph
[23:18] <ARTi> gregaf1 dmick, cheers
[23:33] <elder> sagewk, joshd, the interface on the client side will need to undergo more change if we want to support multiple operations in a single request. I'll tackle that issue when we actually need to do that.
[23:34] <elder> (I mean the kernel client, of course)
[23:34] <sagewk> isn't that already the case with the get_mutable_metadata? like 4 class calls?
[23:34] <elder> That's not what I mean.
[23:34] <elder> The code is set up so you can allocate an array of operations to perform in a single request.
[23:35] <elder> But we only ever allocate one operation now.
[23:35] * bchrisman (~Adium@108.60.121.114) Quit (Quit: Leaving.)
[23:35] <elder> rbd_create_rw_ops()
[23:35] <elder> Maybe there's no need for more than one?
[23:37] <joshd> we'll want more than one there I think
[23:38] <elder> OK, well once we do I'll need to rearrange things some more.
[23:38] <elder> But I can't think too much about that right now...
[23:39] * loicd (~loic@2a01:e35:2eba:db10:120b:a9ff:feb7:cce0) Quit (Quit: Leaving.)
[23:39] * loicd (~loic@2a01:e35:2eba:db10:120b:a9ff:feb7:cce0) has joined #ceph

These logs were automatically created by CephLogBot on irc.oftc.net using the Java IRC LogBot.