#ceph IRC Log

Index

IRC Log for 2011-01-14

Timestamps are in GMT/BST.

[0:08] <sakib> ok, I've sent it
[0:10] <sakib> i also wanted to ask about posix acl support in ceph. Is that being implemented by anyone?
[0:14] <sagewk> not currently, nope.
[0:15] <sagewk> it's in the tracker as #27
[0:17] <sakib> i've just received notification about its removal..
[0:17] <sagewk> sakib: not sure that xattr fix is right.. what about http://fpaste.org/VwAF/ ?
[0:17] * ghaskins (~ghaskins@66-189-113-47.dhcp.oxfr.ma.charter.com) Quit (Ping timeout: 480 seconds)
[0:17] <sagewk> it's only when the lengths are equal that the strncmp result is wrong.. and then only if len(name) > xattr_len, right?
[0:22] <sakib> strcmp() has 2 args
[0:25] <sagewk> er that should be strncmp
[0:26] <sagewk> that's the only case that's broken, tho, right?
[0:27] <Tv|work> sagewk: are both the strings reliably zero-terminated? do you *need* strncmp?
[0:27] <sagewk> the first is, the second normally isn't.. hence xattr->name_len
[0:27] <Tv|work> ah
[0:28] <sagewk> but there's not strcmp variane that takes one null terminated and one explicit length specified string
[0:30] * ajnelson (~Adium@dhcp-63-189.cse.ucsc.edu) Quit (Quit: Leaving.)
[0:31] <Tv|work> yeah.. i tend to like the style that puts strlen first, bails out if lengths are not equal, that reads better for me personally
[0:31] <Tv|work> but since this is about rbtrees i guess you really need to know which one is greater
[0:32] <Tv|work> you could replace the strlen(name) with a name[xattr->name_len] != '\0' but that's just a silly micro-optimization.. apart from that the pastebin looks perfect
[0:34] <sakib> sagewk: it's up to you to choose a variant of fixing that, but anyway, it's better to put strlen() ouside loop
[0:35] <sagewk> right
[0:39] <sakib> pastebin variant is doing strncmp() until xattr is found, while maillist patch variant is doing that only for names with samle length, which aren't so common
[0:40] <Tv|work> sakib: i was going to suggest that, but doesn't the rbtree want to know whether it was <0 or >1
[0:40] <Tv|work> err
[0:40] <Tv|work> <0 or >0
[0:40] <Tv|work> so it needs the cmp anyway
[0:40] <sagewk> sakib: but for those it's not doing strcmp at all if the length doesn't match.. the sort should be lexicographic
[0:45] <sakib> i see. sorry for noise then
[0:45] <sagewk> oh i'm not complaining, just want to get the fix right :)
[0:46] <sakib> :)
[0:46] <Tv|work> <3 users with patches
[0:49] * dallas (~dallas@208.80.64.200) has joined #ceph
[0:50] * dallas (~dallas@208.80.64.200) Quit ()
[0:51] <sagewk> sakib: pushed fix to master branch of ceph-client.git
[0:53] * ceph (~dallas@208.80.64.200) has joined #ceph
[0:53] * ceph (~dallas@208.80.64.200) has left #ceph
[0:54] * dallas (~dallas@208.80.64.200) has joined #ceph
[1:06] * sakib (~sakib@79.124.239.120) Quit (Quit: leaving)
[2:13] * joshd (~joshd@ip-66-33-206-8.dreamhost.com) Quit (Quit: Leaving.)
[2:23] * sjust (~sam@ip-66-33-206-8.dreamhost.com) Quit (Read error: Operation timed out)
[2:26] * bchrisman (~Adium@67.134.140.2) has joined #ceph
[2:28] * Tv|work (~Tv|work@ip-66-33-206-8.dreamhost.com) Quit (Ping timeout: 480 seconds)
[2:43] * fzylogic (~fzylogic@208.80.64.200) Quit (Quit: DreamHost Web Hosting http://www.dreamhost.com)
[2:43] * dallas (~dallas@208.80.64.200) has left #ceph
[3:12] * bchrisman (~Adium@67.134.140.2) Quit (Ping timeout: 480 seconds)
[3:15] * ghaskins (~ghaskins@66-189-113-47.dhcp.oxfr.ma.charter.com) has joined #ceph
[3:28] * Phil1 (~phil@thrift.cs.ILLINOIS.edu) has joined #ceph
[3:30] <Phil1> I have a couple of Ubuntu Lucid systems on which I'd like to play with Ceph. I'm pulling packages from the repositories offered, but it looks like the ceph-kclient source package isn't being built for the Ubuntu targets like it is for Debian
[3:30] <Phil1> I can compile them myself if I have to, but it would be nice if everything were neatly bundled up
[3:38] <Phil1> OK, doing it myself was simple enough, but I might have an excess of Debian experience to make me comfortable with that
[3:53] * Phil1 (~phil@thrift.cs.ILLINOIS.edu) has left #ceph
[3:55] * joshd (~jdurgin@adsl-75-28-69-238.dsl.irvnca.sbcglobal.net) has joined #ceph
[5:03] * joshd (~jdurgin@adsl-75-28-69-238.dsl.irvnca.sbcglobal.net) Quit (Ping timeout: 480 seconds)
[6:44] * ijuz__ (~ijuz@p4FFF6612.dip.t-dialin.net) Quit (Ping timeout: 480 seconds)
[6:53] * ijuz__ (~ijuz@p4FFF7EAA.dip.t-dialin.net) has joined #ceph
[8:03] * Yoric (~David@dau94-10-88-189-211-192.fbx.proxad.net) has joined #ceph
[9:06] * Yoric (~David@dau94-10-88-189-211-192.fbx.proxad.net) Quit (Quit: Yoric)
[9:07] * allsystemsarego (~allsystem@188.27.167.49) has joined #ceph
[10:07] * Yoric (~David@213.144.210.93) has joined #ceph
[10:21] * votz (~votz@dhcp0020.grt.resnet.group.upenn.edu) Quit (Remote host closed the connection)
[10:34] <jantje> sagewk: I can reproduce the btrfs_orphan_commit_root quite consistent with iozone, so let me know if you need anything.
[10:36] <jantje> and I also get "[ 3256.560243] libceph: tid 1068530 timed out on osd1, will reset osd
[10:36] <jantje> quite frequently, don't know how much impact this has on performance
[10:54] * verwilst_ (~verwilst@router.begen1.office.netnoc.eu) has joined #ceph
[11:07] * verwilst_ (~verwilst@router.begen1.office.netnoc.eu) Quit (Quit: Ex-Chat)
[11:41] * allsystemsarego (~allsystem@188.27.167.49) Quit (Ping timeout: 480 seconds)
[11:41] * allsystemsarego (~allsystem@188.27.167.49) has joined #ceph
[11:53] * allsystemsarego (~allsystem@188.27.167.49) Quit (Ping timeout: 480 seconds)
[11:54] * allsystemsarego (~allsystem@188.27.167.49) has joined #ceph
[12:09] * allsystemsarego (~allsystem@188.27.167.49) Quit (Ping timeout: 480 seconds)
[12:09] * allsystemsarego (~allsystem@188.27.167.49) has joined #ceph
[12:16] * allsystemsarego (~allsystem@188.27.167.49) Quit (Quit: Leaving)
[12:48] * votz (~votz@dhcp0020.grt.resnet.group.UPENN.EDU) has joined #ceph
[15:09] * darkfader (~floh@host-93-104-226-28.customer.m-online.net) Quit (Ping timeout: 480 seconds)
[15:14] <jantje> autogen.sh -> cd src/gtest && autoreconf -fvi; fails in my machine
[15:14] <jantje> (unstable branch)
[15:36] <jantje> g++: .libs/librados_la-sctp_crc32.o: No such file or directory
[15:36] <jantje> g++: .libs/librados_la-dyn_snprintf.o: No such file or directory
[15:36] <jantje> g++: .libs/librados_la-armor.o: No such file or directory
[15:36] <jantje> g++: .libs/librados_la-errno.o: No such file or directory
[15:36] <jantje> g++: .libs/librados_la-page.o: No such file or directory
[15:37] <jantje> g++: ./.libs/libcrush.so: No such file or directory
[15:37] <jantje> make[3]: *** [librados.la] Error 1
[15:37] <jantje> (the src/ceph binaries and others are there)
[15:38] <jantje> sagewk: I just changed to unstable, and it's 2x FASTER then unstable
[15:38] <jantje> faster than testing I meant
[16:26] * MarkN (~nathan@59.167.240.178) Quit (Ping timeout: 480 seconds)
[16:30] * MarkN (~nathan@59.167.240.178) has joined #ceph
[16:49] * ajnelson (~Adium@dhcp-225-235.cruznetsecure.ucsc.edu) has joined #ceph
[17:35] * verwilst (~verwilst@router.begen1.office.netnoc.eu) Quit (Quit: Ex-Chat)
[17:44] * ajnelson (~Adium@dhcp-225-235.cruznetsecure.ucsc.edu) Quit (Quit: Leaving.)
[18:00] * ajnelson (~Adium@dhcp-63-189.cse.ucsc.edu) has joined #ceph
[18:06] <greglap> jantje: that "timed out on osd" message usually just means that you haven't communicated with it in a while; it shouldn't be causing you any issues
[18:22] <wido> anybode else having issues with building the current unstable?
[18:23] <wido> "No rule to make target distclean". I guess this is due to the latest unittests (haven't looked at it really closely)
[18:23] <wido> just wanted to see if #666 has been resolved for me
[18:25] * darkfader (~floh@host-93-104-226-28.customer.m-online.net) has joined #ceph
[18:28] * Yoric (~David@213.144.210.93) Quit (Quit: Yoric)
[18:39] * Tv|work (~Tv|work@ip-66-33-206-8.dreamhost.com) has joined #ceph
[18:41] <sagewk> jantje: faster on which workload?
[18:48] * joshd (~joshd@ip-66-33-206-8.dreamhost.com) has joined #ceph
[18:51] * greglap (~Adium@cpe-76-90-239-202.socal.res.rr.com) Quit (Quit: Leaving.)
[18:54] * alexxy (~alexxy@79.173.81.171) Quit (Ping timeout: 480 seconds)
[18:55] * alexxy[home] (~alexxy@79.173.81.171) has joined #ceph
[18:57] * dallas (~dallas@208.80.64.200) has joined #ceph
[18:58] <cmccabe> vstart.sh seems to require the /usr/bin/host program, which isn't anywhere in our deps
[19:00] <Tv|work> cmccabe: i don't expect people to actually use vstart.sh in production, though
[19:01] <cmccabe> tv: I guess adding dependencies just for that would be kind of silly
[19:02] <Tv|work> the question is more, is the failure obvious & easy to correct from the error message; if not, add a if ! command -v host; then echo "$0: needs the command 'host'" 1>&2; exit 1; fi
[19:04] <cmccabe> tv: I think maybe I can eliminate this use of the host command...
[19:05] <cmccabe> also, these new machines don't have killall installed. How bizarre is that?
[19:05] <sagewk> that's psutils iirc?
[19:05] <cmccabe> I'm not really a guru about these things, but I thought killall was pretty much standard
[19:05] <sagewk> anyway, add what you want to flak:/root/packages and then run flak:/root/dist.sh
[19:06] <sagewk> dpkg -S killall on flab to identiy the package
[19:06] <cmccabe> yeah
[19:06] <cmccabe> looks to be provided by psmisc on the old system
[19:06] <Tv|work> cmccabe: killall is *two* standards ;)
[19:07] <Tv|work> (where using the syntax of one on the other leads to pain)
[19:07] <cmccabe> tv: yes, yesterday I had the "pleasure" of finding out what the killall5 binary did
[19:09] <cmccabe> tv: the old killall is like a mean prank... does nothing useful, but brings your system down
[19:12] <Tv|work> trap for the unwary
[19:12] <cmccabe> tv: I've been told that it was installed as just killall on solaris
[19:12] <Tv|work> like naive people running /sbin/reboot directly
[19:13] <cmccabe> tv: debian at least installs it as killall5, but why?
[19:14] <cmccabe> tv: I can't think of a use for that crazy thing. And even if there was, how hard is it to iterate over pids in /proc ?
[19:22] * greglap (~Adium@static-72-67-79-74.lsanca.dsl-w.verizon.net) has joined #ceph
[19:22] <Tv|work> cmccabe: it predates /proc by a long while
[19:26] <cmccabe> tv: yeah, but there had to be some way to do the same thing in sysV
[19:26] <cmccabe> tv: I mean they had ps, right
[19:27] <Tv|work> it was more convenient to provide a binary for the thing -- putting it in $PATH was the mistake..
[19:27] <cmccabe> tv: I guess killall was used in init scripts at that time
[19:27] <greglap> sagewk: everybody else: my train's delayed so assuming no more delays I'll be in about noon...
[19:29] <sagewk> ok
[19:48] * greglap (~Adium@static-72-67-79-74.lsanca.dsl-w.verizon.net) Quit (Ping timeout: 480 seconds)
[19:48] * alexxy[home] (~alexxy@79.173.81.171) Quit (Remote host closed the connection)
[19:50] * greglap (~Adium@166.205.136.105) has joined #ceph
[19:53] * alexxy (~alexxy@79.173.81.171) has joined #ceph
[19:54] * alexxy (~alexxy@79.173.81.171) Quit (Remote host closed the connection)
[19:59] * alexxy (~alexxy@79.173.81.171) has joined #ceph
[20:00] * alexxy (~alexxy@79.173.81.171) Quit (Remote host closed the connection)
[20:03] * Yoric (~David@dau94-10-88-189-211-192.fbx.proxad.net) has joined #ceph
[20:06] <Tv|work> yehudasa: the recent cauthtool changes seem to have completely changed its behavior -- would you be so kind to fix the tests in src/test/cli/cauthtool/*.t ?
[20:06] * alexxy (~alexxy@79.173.81.171) has joined #ceph
[20:06] <Tv|work> i can't even get a --gen-key & --list to work
[20:07] <Tv|work> actually, i can't get --create-keyring & --list to work
[20:07] <cmccabe> tv: I think yehuda is trying to track down something at the moment, why don't I take a look at the auth stuff
[20:07] <Tv|work> cmccabe: sure
[20:08] <cmccabe> just 1min while I double-check overload2
[20:25] * alexxy (~alexxy@79.173.81.171) Quit (Remote host closed the connection)
[20:29] * greglap (~Adium@166.205.136.105) Quit (Quit: Leaving.)
[20:31] * alexxy (~alexxy@79.173.81.171) has joined #ceph
[20:33] * yehuda_hm (~yehuda@ppp-69-232-181-98.dsl.irvnca.pacbell.net) has joined #ceph
[21:11] * bchrisman (~Adium@63.164.47.229) has joined #ceph
[21:39] * bchrisman (~Adium@63.164.47.229) Quit (Quit: Leaving.)
[21:47] * bchrisman (~Adium@63.164.47.229) has joined #ceph
[21:57] <gregaf> stingray: http://pastebin.com/Adgu4ACb should solve your Objecter problem and let you (finally!) generate a journal dump
[21:58] <gregaf> I'll push that into the testing branch after you confirm :)
[22:00] * bchrisman (~Adium@63.164.47.229) Quit (Quit: Leaving.)
[22:00] * bchrisman (~Adium@63.164.47.229) has joined #ceph
[22:11] * yehuda_hm (~yehuda@ppp-69-232-181-98.dsl.irvnca.pacbell.net) Quit (Ping timeout: 480 seconds)
[22:12] <Tv|work> cmccabe: FWIW i'm not convinced the that the ceph startup makes any sense for the unit tests
[22:13] <Tv|work> especially when it seems to want to fiddle with argc etc
[22:16] <wido> I've got something strange. I wanted to test if the eval_repop() (#666) was resolved, it seems it is, but right now my cluster is hanging
[22:16] <wido> There is one VM running with Qemu-RBD and I'm running bonnie++ in it, this ran fine for about 45 minutes and then everything stalled
[22:17] <wido> the logs of the OSD's show that the auto-scrub is still doing it's things, but that's it
[22:17] <wido> "rados -p rbd ls" for example blocks for ever, same goes for the "data", "metadata" and "casdata" pool, but a pool I created a while ago still works
[22:18] <Tv|work> yeah this makes no sense whatsoever:
[22:18] <Tv|work> $ ./src/unittest_encoding -c /foo
[22:18] <Tv|work> error reading config file(s) /foo
[22:18] <Tv|work> cmccabe: why did you think that change was necessary?
[22:18] * Meths_ (rift@91.106.175.219) has joined #ceph
[22:19] <gregaf> wido: what's the status of each of your PGs?
[22:19] <gregaf> maybe one of them has gotten stuck in a non-writeable or otherwise inaccessible state somehow
[22:19] <wido> gregaf: "1064 pgs: 1064 active+clean"
[22:19] <wido> have to say, the pool which is not blocking has only 8 pg's
[22:19] <wido> where the other pools have 256 PG's
[22:21] <gregaf> all your OSDs are up?
[22:21] <gregaf> a down OSD that hasn't been detected yet, or a PG that got stuck, are the only options I can come up with
[22:21] <wido> yes, they are all up, cluster is in a healthy state
[22:22] <wido> it has been hanging for about 2 hours now, waited to see if it woke up
[22:22] <wido> but it didn't, just keeps blocking
[22:23] <gregaf> when you try to do a pool ls does it block right away, or take a while?
[22:23] <gregaf> can you check on what requests are hanging and track down their status across the cluster?
[22:25] * Meths (rift@91.106.136.98) Quit (Ping timeout: 480 seconds)
[22:27] <wido> gregaf: it blocks for ever
[22:28] <wido> My VM is saying: Proces XX has been blocking for 120 seconds...
[22:29] <wido> hey, I think i'm seeing something here, it is just popping up: "failed verifying authorize reply"
[22:29] <wido> this is something that keeps coming back, have seen it a lot in the last few months
[22:29] * Phil1 (~phil@thrift.cs.ILLINOIS.edu) has joined #ceph
[22:30] * Meths_ is now known as Meths
[22:32] <gregaf> wido: hmm, that failed verify means the authentication is failing during the messenger connect
[22:32] <gregaf> and so it bails out
[22:32] <gregaf> yehudasa says maybe it would occur when keys are rotating
[22:33] <gregaf> but it shouldn't happen any other time if your auth stuff is set up correctly
[22:33] <yehudasa> actually it shouldn't happen anyway
[22:33] <yehudasa> the clients need to renew their keys much before they expire
[22:34] <Phil1> I've got the various bits of ceph installed on a few systems on which I'm trying to set up a testbed. When I try to run mkcephfs, I get a segfault in cosd. Transcript and backtrace at http://pastebin.com/kFREvyuq
[22:34] <Phil1> Is this something fixed in the unstable branch, or otherwise a known problem? Is there something I can do to help fix it?
[22:35] <yehudasa> tv: you mentioned cauthtool didn't work?
[22:35] <wido> yehudasa: I've got a issue about it, I have seen this coming back and back
[22:36] <wido> yehudasa: http://tracker.newdream.net/issues/462
[22:37] <wido> right now I can't find it in the OSD logs, nor the monitor logs, it is just the "rados" tool which is giving me those messages at the moment
[22:39] <yehudasa> wido: you can try using 'debug auth = 20'
[22:39] <yehudasa> maybe will give more information
[22:39] <gregaf> Phil1: that backtrace looks familiar
[22:40] <gregaf> did you specify an OSD journal in your ceph.conf?
[22:40] <Phil1> gregaf: no - it even warns me about the performance implications of not having one
[22:41] <gregaf> there was a regression (I think it was a regression, anyway) introduced in v0.24 or so where if you don't specify a journal location it crashes the first time it tries to touch the journal
[22:41] <gregaf> ah, yep, it's broken in the tagged release of v0.24
[22:41] <wido> yehudasa: restart the cluster or just the client?
[22:42] <gregaf> did you build these yourself?
[22:42] <wido> since restarting will get it out of the state where it is
[22:42] <gregaf> Phil1: if so, there's a fix in the current testing branch, which consists only of the latest release and bugfixes :)
[22:42] <Phil1> gregaf: I'm running 0.24.1 from the Ubuntu lucid packages provided
[22:42] <gregaf> ah
[22:42] <Tv|work> yehudasa: the tests are now out of date and i can't get the basics of it to work enough to know what behavior is expected
[22:42] <Phil1> I can switch over to that and see if it works
[22:42] <Tv|work> yehudasa: i can't --create-keyring and then --list it without errors
[22:42] <Phil1> ceph-testing instead of ceph-stable?
[22:43] <gregaf> Phil1: yeah
[22:43] <gregaf> if that's not a problem for you it's probably simplest
[22:43] <Phil1> not at all
[22:43] <gregaf> there'll be another point release soon to fix that and a few others, but it's not out yet
[22:48] <Phil1> http://ceph.newdream.net/debian/dists/lucid/ceph-testing/binary-amd64/Packages
[22:48] <Phil1> Empty :-(
[22:48] <Phil1> packages weren't built
[22:49] <yehudasa> tv: without errors = without the test failing?
[22:49] <yehudasa> wido: both
[22:49] <yehudasa> wido: you don't really need to restart, you can injectargs
[22:50] <Tv|work> yehudasa: well the tests fail, but i can make just trivial command line runs fail outside the clitests too
[22:50] <Tv|work> yehudasa: = i can't figure out how it's even supposed to work = i couldn't fix the tests
[22:50] <yehudasa> tv: can you give me an example for such a command?
[22:50] <Tv|work> $ ./src/cauthtool kring --create-keyring && ./src/cauthtool kring --list
[22:50] <Tv|work> creating kring
[22:50] <Tv|work> 2011-01-14 13:50:29.724873 7fc2b0379720 auth: cannot parse buffer
[22:50] <Tv|work> error reading file kring
[22:51] <gregaf> Phil1: oh, that's why I was asking
[22:51] <gregaf> we don't regularly build packages of the branches
[22:51] <Phil1> I'll just build them myself
[22:51] <Phil1> those would be useful packages to provide
[22:52] <gregaf> oh, sagewk says it's pretty easy to do it, just takes a little while to compile
[22:52] <yehudasa> tv: I guess the usage syntax is bad, but it should be:
[22:52] <gregaf> he's starting them now though
[22:52] <yehudasa> ./cauthtool kring --create-keyring --add-key kring
[22:52] <Tv|work> yehudasa: kring twice?
[22:52] <yehudasa> no
[22:52] <yehudasa> my bad
[22:53] <yehudasa> ./cauthtool kring --create-keyring --add-key
[22:53] <wido> yehudasa: what specific lines would you be searching for? I just injected the args, the mon was already running with debug auth = 20
[22:53] <gregaf> Phil1: we'll have them pushed in 30 minutes or so
[22:53] <Tv|work> yehudasa: so what does just --create-keyring do
[22:53] <wido> I just saw "verify_authorizer could not get service secret for service osd secret_id=537"
[22:53] * bchrisman (~Adium@63.164.47.229) Quit (Ping timeout: 480 seconds)
[22:53] <yehudasa> tv: have no idea, probably just dumps junk to the buffer.. we'll need to fix that
[22:54] <Tv|work> yehudasa: :(
[22:55] <Phil1> gregaf: Thanks. I'll see if I can build them locally a bit quicker
[22:55] <yehudasa> wido: do I have access to that machine?
[22:55] <wido> yes
[22:55] <wido> logger.ceph.widodh.nl and then, ssh root@noisy
[22:58] <wido> yehudasa: "rbd ls" works, but "rados -p rbd ls" doesn't for example
[22:59] <wido> seems something is blocking, not sure if it will be cephx, since the messages are gone now
[23:03] <Tv|work> yehudasa: can you explain cauthtool --bin quickly to me?
[23:03] * Yoric (~David@dau94-10-88-189-211-192.fbx.proxad.net) Quit (Quit: Yoric)
[23:04] <yehudasa> tv: --bin dumps the keyring in the old binary format
[23:04] * bchrisman (~Adium@63.164.47.229) has joined #ceph
[23:04] <Tv|work> yehudasa: ok so --bin is going away?
[23:04] <yehudasa> tv: no.. but we're not going to use it very much
[23:05] <Tv|work> ok
[23:08] <yehudasa> wido: do you have some client that tries to connect all the time?
[23:09] <wido> yehudasa: Yes, could be, I'm testing with phprados a bit, have created a webinterface to manage RADOS
[23:09] <wido> but it is not hammering the cluster
[23:12] <cmccabe> back
[23:20] <gregaf> Phil1: are those packages building okay for you? left out Ubuntu by mistake!
[23:20] <Phil1> they would be, except for the fact that Ubuntu screwed up the packaged of google-perftools, so I couldn't get the build deps lined up
[23:21] <gregaf> screwed up in what way?
[23:22] <Phil1> In lucid, it's only built for i386, not amd64
[23:22] <Phil1> or rather, the shared library component is
[23:22] <gregaf> oh, how odd
[23:22] <Phil1> https://bugs.launchpad.net/ubuntu/+source/google-perftools/+bug/689480
[23:24] <wido> Phil1: you can take the debian packages
[23:24] <Phil1> fixed in a later Ubuntu release, but not (yet, hopefully) for lucid
[23:24] <gregaf> ah
[23:24] <gregaf> hmm, that shouldn't be a required dependency
[23:24] <Phil1> The difference in libcrypto won't mean it won't start?
[23:24] <gregaf> Ceph will build without tcmalloc, it's just better at dealing with Ceph's memory usage profile
[23:25] <gregaf> libcrypto I dunno about, that's a recent switch we had to make due to licensing issues
[23:25] <gregaf> yehudasa did that, does he knwo?
[23:26] <Phil1> since this is entirely about seeing whether I can get it up and running at the moment (worry about perf later), I'll try to build without google-perftools installed (removed from build-deps)
[23:27] <gregaf> yeah
[23:27] <gregaf> you may also need to specify —with-tcmalloc=no when configuring
[23:27] <cmccabe> Phil1: if libcrypto is a problem, installing from tarball is pretty easy
[23:27] <gregaf> I don't recall if the autoconf script will do autodetect or not at this point
[23:27] <cmccabe> er, libcrypto++
[23:28] <Phil1> libcrypto++ is available
[23:28] <Phil1> "checking for malloc in -ltcmalloc... no"
[23:29] <Phil1> config tests for tcmalloc
[23:29] <Phil1> hopefully the result of that gets used correctly
[23:30] <gregaf> it probably does, then, I just remember I needed it at one point
[23:30] <gregaf> but that was probably because I wanted to build without it and I do have the packages ;)
[23:31] <Phil1> building now - gotten through libcrush.a and libmon.a. We'll see howthe rest goes
[23:32] * fzylogic (~fzylogic@208.80.64.200) has joined #ceph
[23:33] <wido> Phil1: I've got some tcmalloc Ubuntu packages if you want, they are in a private repo
[23:33] <Phil1> assuming the autoconf macros are working right, the packages should build fine
[23:35] <yehudasa> wido: could it be that at some point your clock jumped forward and back?
[23:36] <wido> yehudasa: I don't think so, haven't touched the clock. There is no cron running or NTP daemon
[23:37] <wido> but I'm going afk for today, feel free to test on that machine!
[23:37] <wido> ttyl
[23:44] * bchrisman (~Adium@63.164.47.229) Quit (Quit: Leaving.)
[23:45] <yehudasa> tv: do you have a user on the tracker?
[23:55] <Tv|work> yehudasa: yeah
[23:55] <Tv|work> yehudasa: "Tv"

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