#ceph IRC Log

Index

IRC Log for 2011-07-30

Timestamps are in GMT/BST.

[0:02] <sagewk> cmccabe: added that yesterday
[0:02] <sagewk> ceph mon dump --format=json
[0:02] <sagewk> includes the quorum too, so you can tell how many are up
[0:02] <cmccabe> yeah, I have it using that out now
[0:03] <cmccabe> I actually never used the monitor dump command before, just because ceph -s outputs most of the monitor stuff that was interesting to me
[0:03] <sagewk> oh.. you're parsing ceph -s?
[0:03] <cmccabe> no, no
[0:03] <sagewk> phew ok :)
[0:04] <sagewk> i understand
[0:04] <cmccabe> I mean just that in the past that was what I used to read
[0:04] <sagewk> yeah
[0:04] <cmccabe> but it makes sense for the tool to use mon dump
[0:12] * aliguori (~anthony@cpe-70-123-132-139.austin.res.rr.com) has joined #ceph
[0:21] * lx0 (~aoliva@186.214.52.40) has joined #ceph
[0:28] * lxo (~aoliva@9YYAAAEA0.tor-irc.dnsbl.oftc.net) Quit (Ping timeout: 480 seconds)
[0:32] * Dantman (~dantman@S0106001731dfdb56.vs.shawcable.net) Quit (Remote host closed the connection)
[0:35] * yoshi (~yoshi@KD027091032046.ppp-bb.dion.ne.jp) Quit (Remote host closed the connection)
[0:36] * Dantman (~dantman@S0106001731dfdb56.vs.shawcable.net) has joined #ceph
[0:49] <cmccabe> does anyone remember what the print command was designed to do in cephtool?
[0:50] <cmccabe> it looks suspiciously like deadcode
[0:55] <gregaf> cmccabe: what print command?
[0:55] <cmccabe> gregaf: apparently just typing "print" inside cephtool prints some lines on the screen
[0:56] <cmccabe> gregaf: but examining the code, that is the only effect it can have
[0:56] * dwm (~dwm@vm-shell4.doc.ic.ac.uk) Quit (Read error: Connection reset by peer)
[0:56] <cmccabe> specifically it prints "----" followed by another "----"
[0:56] <cmccabe> I think it must have been for testing or something?
[0:57] * jojy (~jojyvargh@70-35-37-146.static.wiline.com) has joined #ceph
[0:57] <gregaf> hmm, yeah, it's not something I recognize
[0:58] <jojy> how do i file a bug in the ceph bugtracker. Need an account ?
[0:59] <gregaf> jojy: yeah, you need to register
[0:59] <gregaf> http://tracker.newdream.net/account/register
[0:59] <gregaf> I don't think it's locked down at all for reporter accounts
[1:00] <jojy> thx!
[1:03] * jojy (~jojyvargh@70-35-37-146.static.wiline.com) Quit (Quit: jojy)
[1:22] <cmccabe> sagewk: so Kyle has a question about how we should deploy collectd.
[1:23] <cmccabe> sagewk: he was thinking of porting my changes to a debian upstream
[1:23] * kbad (~Adium@ip-64-111-111-107.dreamhost.com) has joined #ceph
[1:23] <cmccabe> sagewk: and I think he also thought about getting the collectd changes into debian backports
[1:24] <kbad> I miss much?
[1:24] <cmccabe> sagewk: I was more envisioning getting the collectd changes into the collectd upstream first, and letting them get merged into debian just by the normal process of debian pulling from upstream
[1:24] <cmccabe> kbad: not much
[1:24] <kbad> k
[1:25] <Tv> cmccabe: into debian stable?
[1:25] <kbad> no
[1:25] <kbad> backports
[1:25] <Tv> ah that sounds more realistic
[1:25] <kbad> stable won't accept features like this in a frozen release :)
[1:26] <Tv> hence my mind conjuring images of ice ages
[1:26] <cmccabe> I can see how that would be helpful but I'm just a little worried about the porting process
[1:26] <cmccabe> I was sort of expected that we'd deploy my code as-is, or just make a simple binary package
[1:26] <cmccabe> *expecting
[1:26] <Tv> what are the relevant version numbers?
[1:27] <kbad> the alternative is I have the cookbooks build it from source ever time, until there is a debian package then I can detect that release and install from package instead
[1:27] <Tv> if they're close, you can probably just slap the packaging on top of the latest upstream, adjust version number, build
[1:27] <kbad> but then you have to wait for it to compile each chef run
[1:27] <kbad> on all the machines
[1:27] <kbad> which is less than desireable
[1:27] <kbad> *desirable
[1:27] <cmccabe> kbad: I think tv was talking about building the dpkg once, then distributing it somehow
[1:28] <kbad> for another release?
[1:28] <cmccabe> kbad: well I mean similar to the ndn repo
[1:28] <kbad> Tv: I tried that
[1:28] <kbad> Tv: they are too far off
[1:28] * yoshi (~yoshi@KD027091032046.ppp-bb.dion.ne.jp) has joined #ceph
[1:28] <Tv> ah
[1:29] <cmccabe> oddly enough, make distcheck fails for me with some kind of error about the perl modules... which I didn't edit
[1:29] <kbad> right, all the packages in there
[1:29] <kbad> are backports
[1:29] <cmccabe> I'm not sure if distcheck is just not working on upstream, or my makefile.am changes weren't as clever as I thought
[1:29] <cmccabe> it's an autohell project, of course...
[1:32] <cmccabe> so anyway
[1:33] <cmccabe> if we're going to rebase everything on a specific debian version, that's ok. But let's at least still use version control on that
[1:34] <cmccabe> it probably makes sense for me to develop any new features in that branch, so to speak
[1:34] <cmccabe> I needed to repackage my changes before sending to upstream anyway, so this isn't that big of a deal.
[1:35] <Tv> cmccabe: the git repo with the deb packaging is http://packages.qa.debian.org/c/collectd.html
[1:35] <Tv> *is on
[1:35] <Tv> you could do a proper vcs thing with it
[1:36] <Tv> but i see Kyle's point, 4.0 vs 5.0 is a huge difference
[1:36] <Tv> we might get off easier using 4.0
[1:39] <cmccabe> tv: I think we can use version control AND base our changes off of an older version
[1:39] <cmccabe> tv: the repo has a bunch of tags which seem to represent debian versions, so which one do we want?
[1:40] <Tv> the one that's in squeeze
[1:41] <cmccabe> tv: hmm, there's no actual source code in this repo
[1:41] <cmccabe> tv: just a list of patches...
[1:41] <kbad> for quilt presumably?
[1:42] <cmccabe> kbad: "dpatch"
[1:42] <kbad> yeah, that's how debian keeps their patches separate from upstream source
[1:42] <kbad> then they quilt their patches together with the original frozen upstream source
[1:43] <kbad> so you'd essentially be making another patch, correct me if I'm wrong TV
[1:44] * Tv (~Tv|work@ip-64-111-111-107.dreamhost.com) Quit (Read error: Operation timed out)
[1:46] <cmccabe> I have a suspicion that all of this is going to be more work than just building the repo that I have now and installing that
[1:46] <cmccabe> but I don't really know the answers to these questions.
[1:47] <kbad> I'm not even sure squeeze will satisfy all the depends for a 5.0 build
[1:47] <kbad> and then you have to start backporting depends
[1:47] <kbad> it gets really ugly really quick
[1:47] <cmccabe> I don't think collectd really has any depends
[1:47] <kbad> it has all kinds of build time dependencies
[1:47] <cmccabe> cmccabe@metropolis:~/src/collectd$ ldd /opt/collectd/sbin/collectd
[1:47] <cmccabe> linux-vdso.so.1 => (0x00007ffffcb92000)
[1:47] <cmccabe> librt.so.1 => /lib/librt.so.1 (0x00007f73b7590000)
[1:47] <cmccabe> libpthread.so.0 => /lib/libpthread.so.0 (0x00007f73b7374000)
[1:47] <cmccabe> libltdl.so.7 => /usr/lib/libltdl.so.7 (0x00007f73b716a000)
[1:47] <cmccabe> libdl.so.2 => /lib/libdl.so.2 (0x00007f73b6f66000)
[1:47] <cmccabe> libc.so.6 => /lib/libc.so.6 (0x00007f73b6c05000)
[1:47] <cmccabe> /lib64/ld-linux-x86-64.so.2 (0x00007f73b77aa000)
[1:48] <cmccabe> so... if you have pthreads, and glibc, and libtool
[1:49] <cmccabe> then I think you'll be ok
[1:49] <cmccabe> you also need libjson-c for ceph.so
[1:49] <kbad> those are all run time though, right?
[1:49] <cmccabe> yes
[1:49] <kbad> I'm talking about build depends
[1:49] <cmccabe> but like what? collectd has a bunch of options, but you don't have to enable them.
[1:51] <kbad> why can't you just take our word on this?
[1:51] * kbad (~Adium@ip-64-111-111-107.dreamhost.com) Quit (Quit: Leaving.)
[1:58] <cmccabe> heh. I hope I didn't ruin his friday
[1:59] <cmccabe> but still, I think anyone who builds collectd from source will have to admit that the dependencies are very minimal. It's really incredibly rare to find a package like that these days.
[1:59] <cmccabe> anyway, the debian backporting thing sounds like something we will do, we'll talk about it later.
[2:01] <sagewk> cmccabe: i think half of it is also changes in the debian packaging itself. but yeah, let's see how hard a rebase is before fighting it too hard
[2:02] <sagewk> ttyl everyone, have a good weekend!
[2:03] <cmccabe> have a good one.
[2:28] * aliguori (~anthony@cpe-70-123-132-139.austin.res.rr.com) Quit (Ping timeout: 480 seconds)
[2:37] * aliguori (~anthony@cpe-70-123-132-139.austin.res.rr.com) has joined #ceph
[2:37] * bchrisman (~Adium@70-35-37-146.static.wiline.com) Quit (Quit: Leaving.)
[2:44] * aliguori (~anthony@cpe-70-123-132-139.austin.res.rr.com) Quit (Quit: Ex-Chat)
[2:53] * huangjun (~IceChat77@61.184.205.201) has joined #ceph
[2:54] [huangjun VERSION]
[3:07] * cmccabe (~cmccabe@69.170.166.146) Quit (Quit: Leaving.)
[3:27] <huangjun> hi,all
[3:27] <sjust> hi
[3:28] <huangjun> ceph have readahead in OSD?
[3:28] <sjust> you mean to speed up client requests?
[3:28] <sjust> no
[3:29] <huangjun> why?
[3:29] <sjust> well, nothing more than what the underlying file system provides
[3:29] <huangjun> we think it should keep the former read data in bufferlist
[3:29] <huangjun> and next time,it will get it quickly
[3:29] <sjust> I don't quite follow
[3:30] <sjust> ah
[3:30] <sjust> you think the OSD should implement a read cache?
[3:30] <huangjun> yes
[3:30] <sjust> well, the underlying filesystem already provides that to some degree
[3:30] <huangjun> uhmm
[3:31] <sjust> one argument is that the caching should be handled by the client
[3:32] <huangjun> so what in road of read low performance?
[3:32] <sjust> I don't understand
[3:33] <huangjun> yesterday, we implement a CEPH_OSD_OP_READAHEAD op
[3:33] <sjust> as a way of forcing the OSD to cache an object?
[3:34] <huangjun> yes,but it shouldn't reply to client
[3:34] <sjust> ok
[3:34] * yoshi (~yoshi@KD027091032046.ppp-bb.dion.ne.jp) Quit (Remote host closed the connection)
[3:34] <huangjun> the problem is that client should caculate the next object infos
[3:35] <sjust> object infos?
[3:36] <huangjun> it should know which OSD the message sent to
[3:36] <sjust> yes, the client would need to determine which osd to send the op to
[3:37] <huangjun> but we always get 0 bytes
[3:37] <huangjun> maybe,we do something wrong in this
[3:38] <sjust> 0 bytes from what?
[3:39] <huangjun> caculate the next object layout, offset~len is 0~0
[3:39] <sjust> oh, from cephfs?
[3:39] <sjust> ok
[3:40] <huangjun> from osdc
[3:41] <sjust> what methods are you using to determine the object location?
[3:42] <huangjun> like steps done of READ op
[3:42] <sjust> in ::op_submit?
[3:43] <huangjun> op_sumbit
[3:43] <sjust> recalc_op_target seems to have the logic for determining which osd to send the request to
[3:44] <sjust> I need to head home, I'll be happy to help you more on Monday, though
[3:44] <sjust> alternately, you could send an email to the list
[3:44] <huangjun> thks
[3:44] <sjust> '
[3:49] <sjust> huanjun: I should mention that osdc/ObjectCacher.* implement a client side object cache, I think
[3:49] <sjust> anyway, have a good weekend
[3:49] <huangjun> you too
[3:50] <huangjun> are you in San Francisco?
[3:54] * jojy (~jojyvargh@75-54-231-2.lightspeed.sntcca.sbcglobal.net) has joined #ceph
[3:55] * jojy (~jojyvargh@75-54-231-2.lightspeed.sntcca.sbcglobal.net) Quit ()
[3:59] * votz_ (~votz@pool-72-78-219-212.phlapa.fios.verizon.net) Quit (Quit: Leaving)
[4:00] * joshd (~joshd@ip-64-111-111-107.dreamhost.com) Quit (Quit: Leaving.)
[4:32] * huangjun (~IceChat77@61.184.205.201) Quit (Quit: Light travels faster then sound, which is why some people appear bright, until you hear them speak)
[4:33] * huangjun (~IceChat77@61.184.205.201) has joined #ceph
[5:45] <huangjun> ok,it may be night in America
[6:09] * bchrisman (~Adium@c-98-207-207-62.hsd1.ca.comcast.net) has joined #ceph
[6:29] * yehuda_hm (~yehuda@99-48-179-68.lightspeed.irvnca.sbcglobal.net) has joined #ceph
[6:44] * DanielFriesen (~dantman@S0106001731dfdb56.vs.shawcable.net) has joined #ceph
[6:49] * Dantman (~dantman@S0106001731dfdb56.vs.shawcable.net) Quit (Ping timeout: 480 seconds)
[8:16] * Nadir_Seen_Fire (~dantman@S0106001731dfdb56.vs.shawcable.net) has joined #ceph
[8:18] * DanielFriesen (~dantman@S0106001731dfdb56.vs.shawcable.net) Quit (Read error: Operation timed out)
[8:21] * yehuda_hm (~yehuda@99-48-179-68.lightspeed.irvnca.sbcglobal.net) Quit (Ping timeout: 480 seconds)
[8:41] * DanielFriesen (~dantman@S0106001731dfdb56.vs.shawcable.net) has joined #ceph
[8:47] * Nadir_Seen_Fire (~dantman@S0106001731dfdb56.vs.shawcable.net) Quit (Ping timeout: 480 seconds)
[8:52] * yoshi (~yoshi@KD027091032046.ppp-bb.dion.ne.jp) has joined #ceph
[9:08] * kbad (~Adium@pool-108-38-208-174.lsanca.fios.verizon.net) has joined #ceph
[9:08] * kbad (~Adium@pool-108-38-208-174.lsanca.fios.verizon.net) has left #ceph
[10:16] * yoshi (~yoshi@KD027091032046.ppp-bb.dion.ne.jp) Quit (Remote host closed the connection)
[10:28] * lx0 (~aoliva@186.214.52.40) Quit (Ping timeout: 480 seconds)
[10:28] * lx0 (~aoliva@9YYAAAEUK.tor-irc.dnsbl.oftc.net) has joined #ceph
[14:45] * phil_ (~quassel@chello080109010223.16.14.vie.surfer.at) has joined #ceph
[15:32] * huangjun (~IceChat77@61.184.205.201) Quit (Quit: I used to think I was indecisive, but now I'm not too sure.)
[18:00] * jim (~chatzilla@astound-69-42-16-6.ca.astound.net) Quit (Remote host closed the connection)
[18:17] * DLange (~DLange@dlange.user.oftc.net) Quit (Quit: time for a reboot)
[18:21] * DLange (~DLange@dlange.user.oftc.net) has joined #ceph
[18:49] * jim (~chatzilla@astound-69-42-16-6.ca.astound.net) has joined #ceph
[19:30] * phil_ (~quassel@chello080109010223.16.14.vie.surfer.at) Quit (Remote host closed the connection)

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