#ceph IRC Log

Index

IRC Log for 2011-07-05

Timestamps are in GMT/BST.

[0:41] * MK_FG (~MK_FG@188.226.51.71) has joined #ceph
[1:13] * sugoruyo (~george@athedsl-411617.home.otenet.gr) Quit (Quit: sugoruyo)
[1:37] * yoshi (~yoshi@p15251-ipngn1601marunouchi.tokyo.ocn.ne.jp) has joined #ceph
[2:40] * yoshi (~yoshi@p15251-ipngn1601marunouchi.tokyo.ocn.ne.jp) Quit (Remote host closed the connection)
[2:46] * yoshi (~yoshi@p15251-ipngn1601marunouchi.tokyo.ocn.ne.jp) has joined #ceph
[3:36] * jantje (~jan@paranoid.nl) Quit (Ping timeout: 480 seconds)
[5:25] * jantje (~jan@paranoid.nl) has joined #ceph
[9:38] * DanielFriesen (~dantman@S0106001731dfdb56.vs.shawcable.net) has joined #ceph
[9:42] * Dantman (~dantman@S0106001731dfdb56.vs.shawcable.net) Quit (Ping timeout: 480 seconds)
[11:40] * yoshi (~yoshi@p15251-ipngn1601marunouchi.tokyo.ocn.ne.jp) Quit (Remote host closed the connection)
[12:25] * jiaju (~jjzhang@222.126.194.154) has joined #ceph
[12:31] * jiaju (~jjzhang@222.126.194.154) Quit (Quit: ??????)
[12:34] * jiaju (~jjzhang@222.126.194.154) has joined #ceph
[12:43] * jiaju (~jjzhang@222.126.194.154) Quit (Quit: ??????)
[12:46] * jiaju (~jjzhang@222.126.194.154) has joined #ceph
[13:03] * jiaju (~jjzhang@222.126.194.154) Quit (Remote host closed the connection)
[13:34] * ghaskins (~ghaskins@66-189-113-47.dhcp.oxfr.ma.charter.com) Quit (Read error: Operation timed out)
[14:25] * ghaskins (~ghaskins@66-189-113-47.dhcp.oxfr.ma.charter.com) has joined #ceph
[15:14] * aliguori (~anthony@cpe-70-123-132-139.austin.res.rr.com) has joined #ceph
[16:40] * jiaju (~jjzhang@125.34.2.217) has joined #ceph
[16:48] * NashTrash (~Adium@129.59.105.122) has joined #ceph
[16:49] * greglap (~Adium@166.205.138.46) has joined #ceph
[16:55] <NashTrash> Good morning Ceph'ers!
[16:56] <greglap> morning NashTrash
[16:56] <NashTrash> How are you today?
[16:57] <greglap> my 3-day weekend has ended :(
[16:57] <greglap> ;)
[16:57] <NashTrash> I hear you. Back to the salt mines.
[16:58] <NashTrash> I did have some time over the weekend to continue playing with my setup. I upgraded all of my servers to 3.0rc5 which gives me btrfs v0.19.
[16:58] <NashTrash> I know this is a completely noob question, but...
[16:59] <NashTrash> Before I mkfs.btrfs, do I have to run fdisk to create a partition on the disks? I tried it without setting up any partition and nothing seemed to puke outright.
[17:00] <greglap> I believe that mkfs.btrfs does everything
[17:01] <greglap> although I'm pretty noob myself about the day-to-day admin stuff
[17:09] <NashTrash> Ok. I then ran mkcephfs and things seemed to go well (note: I did not use ???mkbtrfs). But now my little cluster is not happy.
[17:09] <NashTrash> It looks like I have OSD failures and maybe an MDS failure. I am still not great at interpreting what ceph -s output means.
[17:10] <NashTrash> root@cloudstore1:~# ceph -s
[17:10] <NashTrash> 2011-07-05 10:10:06.013191 pg v9361: 990 pgs: 3 inactive, 784 active+clean, 107 peering, 7 active+clean+degraded, 86 crashed+down+peering, 3 crashed+down+degraded+peering; 24 KB data, 2179 MB used, 7439 GB / 7452 GB avail
[17:10] <NashTrash> 2011-07-05 10:10:06.015412 mds e18: 1/1/1 up {0=0=up:replay}, 1 up:standby
[17:10] <NashTrash> 2011-07-05 10:10:06.015507 osd e1938: 4 osds: 2 up, 2 in
[17:10] <NashTrash> 2011-07-05 10:10:06.015596 log 2011-07-05 10:02:26.975165 osd3 192.168.48.4:6800/18360 395 : [INF] 2.0p4 scrub ok
[17:10] <NashTrash> 2011-07-05 10:10:06.015756 mon e1: 2 mons at {0=192.168.48.247:6789/0,1=192.168.48.248:6789/0}
[17:10] <greglap> so if you have OSD failures then any MDS failure on startup *probably* follows from that since the MDS uses the OSDs for storage
[17:10] <greglap> in this case your MDS is in replay though, which isn't a failure mode (though it may be hanging there waiting on the OSDs, in which case it will eventually time out)
[17:11] <greglap> why didn't you use --mkbtrfs?
[17:12] <greglap> I'm not sure but I think that's what you want unless you're setting the osd data to live in a subdirectory
[17:12] <NashTrash> Since I created the btrfs's by hand. I did set the OSD data directory by hand and manually created those directories.
[17:13] <NashTrash> I have two hard drives in a btrfs volume on each OSD. I wanted to make sure the btrfs stuff underneath was working properly before I got Ceph working.
[17:13] <greglap> okay, we can work through it if you like, it's just that the config is easier if you give the OSDs a raw partition to work on and tell them to set it up themselves :)
[17:14] <greglap> so if you do ceph osd dump -o - you'll get the OSD map dumped to stdout
[17:14] <NashTrash> Really, I am open either way. Here is my current ceph.conf: http://pastebin.com/YYrR1ZjE
[17:15] <NashTrash> root@cloudstore1:~# ceph osd dump -o -
[17:15] <NashTrash> 2011-07-05 10:14:58.430179 mon <- [osd,dump]
[17:15] <NashTrash> 2011-07-05 10:14:58.430997 mon0 -> 'dumped osdmap epoch 1938' (0)
[17:15] <NashTrash> epoch 1938
[17:15] <NashTrash> fsid bb3da3d1-8cd7-6fc5-0b27-0dccd9397f0d
[17:15] <NashTrash> created 2011-07-03 09:55:59.912353
[17:15] <NashTrash> modifed 2011-07-05 10:07:56.980715
[17:15] <NashTrash> flags
[17:15] <NashTrash> pg_pool 0 'data' pg_pool(rep pg_size 2 crush_ruleset 0 object_hash rjenkins pg_num 320 pgp_num 320 lpg_num 2 lpgp_num 2 last_change 1 owner 0)
[17:15] <NashTrash> pg_pool 1 'metadata' pg_pool(rep pg_size 2 crush_ruleset 1 object_hash rjenkins pg_num 320 pgp_num 320 lpg_num 2 lpgp_num 2 last_change 1 owner 0)
[17:15] <NashTrash> pg_pool 2 'rbd' pg_pool(rep pg_size 2 crush_ruleset 2 object_hash rjenkins pg_num 320 pgp_num 320 lpg_num 2 lpgp_num 2 last_change 1 owner 0)
[17:15] <NashTrash> max_osd 5
[17:15] <NashTrash> osd0 up in weight 1 up_from 1931 up_thru 1936 down_at 1930 last_clean_interval 1919-1929 192.168.48.1:6800/21037 192.168.48.1:6801/21037 192.168.48.1:6802/21037
[17:15] <NashTrash> osd1 down out up_from 3 up_thru 5 down_at 1925 last_clean_interval 0-0
[17:15] <NashTrash> osd2 down out up_from 1906 up_thru 1906 down_at 1908 last_clean_interval 5-1905
[17:15] <NashTrash> osd3 up in weight 1 up_from 1922 up_thru 1935 down_at 1921 last_clean_interval 4-1920 192.168.48.4:6800/18360 192.168.48.4:6801/18360 192.168.48.4:6802/18360
[17:15] <greglap> okay, so osd1 and osd2 are down
[17:15] <NashTrash> osd4 doesn't even show up!
[17:16] <greglap> oh, odd
[17:16] <greglap> was it in when you created the cluster, or did you add it later?
[17:16] <NashTrash> As I said, I am happy to work this however you prefer. OSD 4 has always been a part.
[17:17] <NashTrash> I am happy to wipe everything and start over too.
[17:17] <greglap> nah, let's see what broke
[17:17] <greglap> I'm not sure how an OSD could get removed from the map without explicit instructions, was it ever in there?
[17:18] <greglap> as for the rest, look at osd1 and 2 and let's see why they're down
[17:18] <NashTrash> I don't believe it ever was. As soon as I ran the first "service ceph -a start" I don't remember it showing up.
[17:18] <greglap> you should have backtraces at the end of the logs
[17:19] <greglap> okay, something going wrong in initialization is better than our monitors going crazy, but somebody else will need to check that out
[17:19] <greglap> and if you need the journal and the data dir to live on the same partition I think you're going to need to do the setup yourself anyway
[17:20] <greglap> (your ceph.conf looks fine, btw)
[17:20] <NashTrash> here is the last few lines from osd.1.log:
[17:20] <NashTrash> 2011-07-05 08:32:06.589514 7f84b4d95700 osd1 5 heartbeat_check: no heartbeat from osd2 since 2011-07-03 09:57:02.411811 (cutoff 2011-07-05 08:31:46.589503)
[17:20] <NashTrash> 2011-07-05 08:32:06.779728 7f84b769b700 -- 192.168.48.2:6800/1812 send_message dropped message auth(proto 2 128 bytes) v1 because of no pipe on con 0x272a470
[17:20] <NashTrash> 2011-07-05 08:32:06.779752 7f84b769b700 -- 192.168.48.2:6800/1812 send_message dropped message auth(proto 2 2 bytes) v1 because of no pipe on con 0x272a470
[17:20] <NashTrash> 2011-07-05 08:32:06.779767 7f84b769b700 -- 192.168.48.2:6800/1812 send_message dropped message mon_subscribe({monmap=2+,osdmap=3}) v1 because of no pipe on con 0x272a470
[17:20] <NashTrash> 2011-07-05 08:32:07.063791 7f84be6a9700 osd1 5 heartbeat_check: no heartbeat from osd2 since 2011-07-03 09:57:02.411811 (cutoff 2011-07-05 08:31:47.063780)
[17:20] <NashTrash> 2011-07-05 08:32:07.189823 7f84b4d95700 osd1 5 heartbeat_check: no heartbeat from osd2 since 2011-07-03 09:57:02.411811 (cutoff 2011-07-05 08:31:47.189809)
[17:20] <NashTrash> 2011-07-05 08:32:08.063993 7f84be6a9700 osd1 5 heartbeat_check: no heartbeat from osd2 since 2011-07-03 09:57:02.411811 (cutoff 2011-07-05 08:31:48.063982)
[17:20] <NashTrash> 2011-07-05 08:32:08.590168 7f84b4d95700 osd1 5 heartbeat_check: no heartbeat from osd2 since 2011-07-03 09:57:02.411811 (cutoff 2011-07-05 08:31:48.590157)
[17:20] <NashTrash> 2011-07-05 08:32:09.064186 7f84be6a9700 osd1 5 heartbeat_check: no heartbeat from osd2 since 2011-07-03 09:57:02.411811 (cutoff 2011-07-05 08:31:49.064175)
[17:20] <NashTrash> 2011-07-05 08:32:09.064226 7f84be6a9700 -- 192.168.48.2:6800/1812 send_message dropped message osd_alive(want up_thru 5 have 5) v1 because of no pipe on con 0x272a470
[17:20] <NashTrash> 2011-07-05 08:32:09.064244 7f84be6a9700 -- 192.168.48.2:6800/1812 send_message dropped message osd_pgtemp(e5 {0.47=[],1.46=[],2.45=[],2.1p1=[]} v5) v1 because of no pipe on con 0x272a470
[17:20] <NashTrash> 2011-07-05 08:32:09.064257 7f84be6a9700 -- 192.168.48.2:6800/1812 send_message dropped message osd_failure(osd2 192.168.48.3:6800/1825 e5 v5) v1 because of no pipe on con 0x272a470
[17:20] <NashTrash> 2011-07-05 08:32:09.064490 7f84be6a9700 -- 192.168.48.2:6800/1812 send_message dropped message pg_stats(240 pgs v 5) v1 because of no pipe on con 0x272a470
[17:20] <NashTrash> 2011-07-05 08:32:09.612599 7f84b3390700 -- 192.168.48.2:6802/1812 >> 192.168.48.1:6802/2042 pipe(0x272d5f0 sd=14 pgs=2 cs=1 l=0).fault with nothing to send, going to standby
[17:20] <NashTrash> 2011-07-05 08:32:09.990463 7f84b4d95700 osd1 5 heartbeat_check: no heartbeat from osd2 since 2011-07-03 09:57:02.411811 (cutoff 2011-07-05 08:31:49.990453)
[17:20] <NashTrash> 2011-07-05 08:32:09.990715 7f84b328f700 -- 192.168.48.2:6802/1812 >> 192.168.48.1:6802/2042 pipe(0x272d5f0 sd=14 pgs=2 cs=2 l=0).fault first fault
[17:20] <NashTrash> 2011-07-05 08:32:10.064853 7f84be6a9700 osd1 5 heartbeat_check: no heartbeat from osd2 since 2011-07-03 09:57:02.411811 (cutoff 2011-07-05 08:31:50.064842)
[17:20] <NashTrash> *** Caught signal (Terminated) **
[17:20] <NashTrash> in thread 0x7f84c3714740. Shutting down.
[17:20] <NashTrash> 2011-07-05 08:32:24.558796 7f13d42b2740 ceph version 0.30.commit: 64b1b2c70f0cde39c72d5d724c65ea8afaaa00b9. process: cosd. pid: 19077
[17:20] <NashTrash> I recently tried stoping and restarting all of the cluster, but some of the OSDs wouldn't stop.
[17:23] <greglap> that's the end of the log? I'd expect there to be a few more lines following that contain info about the stack
[17:26] <NashTrash> That's it. Sorry.
[17:27] <greglap> hmmm
[17:27] <NashTrash> I can not kill this OSD either. Nothing short of a reboot.
[17:27] <greglap> I'll have to ask Colin if the signal handler got adjusted, that might also just be the OSD responding to a kill signal from the OSD
[17:28] <greglap> *from the OS
[17:28] <greglap> you can't kill osd1?
[17:28] <greglap> the process isn't already gone?
[17:28] <NashTrash> Nope. service ceph stop on that machine just spits out an endless stream of "kill 19078??????.kill 19078....."
[17:30] <greglap> oh, I bet you hit the zombie process bug that wido was talking about ??? don't think we've seen that anywhere else!
[17:30] <NashTrash> Hey, I am lucky :)
[17:32] <greglap> oh, what's in dmesg?
[17:32] <greglap> are there btrfs failures there?
[17:33] <NashTrash> Yes. Here is the paste: http://pastebin.com/8TqvHxLQ
[17:36] <greglap> ungh
[17:36] <NashTrash> Is there a specific kernel version I should try? 3.0rc5 might not be it!
[17:36] <greglap> so that's likely the problem, but I'm going to have to pass it to somebody else when they get in
[17:37] <greglap> sorry, I just don't know that much about btrfs issues :(
[17:37] <greglap> (and my train's at the station, I'll be back in a bit)
[17:37] <NashTrash> Ok. I am around most of the day. Just ping me when you have time.
[17:37] * greglap (~Adium@166.205.138.46) Quit (Quit: Leaving.)
[17:42] * bchrisman (~Adium@c-98-207-207-62.hsd1.ca.comcast.net) Quit (Quit: Leaving.)
[17:45] <wido> hi guys
[17:45] <wido> I got some messages about a "bad locator", are those serious?
[17:55] * Tv (~Tv|work@ip-64-111-111-107.dreamhost.com) has joined #ceph
[18:32] * cmccabe (~cmccabe@c-24-23-254-199.hsd1.ca.comcast.net) has joined #ceph
[18:33] * bchrisman (~Adium@70-35-37-146.static.wiline.com) has joined #ceph
[18:36] <sagewk> wido: hmm, probabaly a bug
[18:36] <sagewk> do you have logs?
[18:36] <sagewk> wido: also did you see my comment on #1032? for next time it comes up
[18:53] <wido> sagewk: I'll dig around in my logs, now I know that it's a bug I'll make a report
[18:54] <sagewk> wido: i'd call it 'a possible btrfs performance issue'.. we
[18:54] <sagewk> 'll see what it's really up to
[18:54] * joshd (~joshd@ip-64-111-111-107.dreamhost.com) has joined #ceph
[18:54] <wido> sagewk: I think so too, since I see the btrfs-cleaner processes running
[18:54] <sagewk> er, 1032 i mean. the bad locator sounds like a bug ;)
[18:54] <wido> I didn't get a update from Redmine btw about 1032
[18:55] <sagewk> an email you mean?
[18:55] <wido> yes, no e-mail
[18:55] <sagewk> weird :/
[18:55] <wido> I'll keep an eye on the bad locator and make a report if I see it again or if there is something in my logs
[19:10] <wido> got to go, ttyl
[20:37] * jiaju (~jjzhang@125.34.2.217) Quit (Ping timeout: 480 seconds)
[20:37] * jiaju (~jjzhang@125.34.2.217) has joined #ceph
[20:37] * jiaju (~jjzhang@125.34.2.217) Quit ()
[22:44] <Tv> i still get a 500 internal error at s3-tests setup time if i run it via teuthology
[22:44] <Tv> joshd: did it actually work for you? does it still work for you?
[22:45] <joshd> Tv: it worked on v0.30 with the users enabled after being created
[22:45] <joshd> Tv: it could also be an issue of having the right packages
[22:46] <joshd> Tv: I updated the fabfile last week, but I don't know if the machines have been updated since then
[22:46] <Tv> /tmp/cephtest/binary/usr/local/bin/radosgw: error while loading shared libraries: librgw.so.1: cannot open shared object file: No such file or directory
[22:47] <joshd> don't tell me my test machine still had old ceph packages installed...
[22:47] <cmccabe> tv: I believe that autotest embeds absolute paths into shared libraries
[22:47] <cmccabe> tv: "Libtool's use of `-rpath' has been a point of contention for some users, since it prevents you from moving shared libraries to another location in the library search path. Or, at least, if you do, all of the executables that were linked with `-rpath' set to the old location will need to be relinked"
[22:47] <Tv> cmccabe: "autotest"?
[22:47] <cmccabe> tv: from http://sourceware.org/autobook/autobook/autobook_88.html
[22:48] <cmccabe> sorry, meant to say libtool
[22:48] <Tv> cmccabe: we already successfully use LD_LIBRARY_PATH in many places
[22:48] <cmccabe> tv: so this is more fallout from not doing make install
[22:48] <cmccabe> tv: LD_LIBRARY_PATH seems like it should save the day if you use it though.
[22:49] <cmccabe> try ldd, see where it's looking
[22:49] <Tv> cmccabe: it's a problem of not setting up apache/fcgi right
[22:49] <joshd> Tv: in the apache conf I am setting LD_LIBRARY_PATH
[22:50] <cmccabe> I don't know how LD_LIBRARY_PATH interacts with fgci
[22:50] <cmccabe> I assume apache passes its environment to its sub-processes, but maybe not
[22:50] <cmccabe> security folks tend to get nervous about things like that
[22:51] <Tv> joshd: uhh are the quotes on SetEnv ok, or are they passed straight into the env vars.. docs say "SetEnv SPECIAL_PATH /foo/bin" no quotes
[22:51] <Tv> cmccabe: you're not really helping
[22:53] <cmccabe> tv: well, hopefully I'm not harming
[22:53] <cmccabe> tv: anyway sounds like you have it under control
[22:53] <joshd> Tv: does it work for you without the quotes, or do we need to set LD_LIBRARY_PATH in the fcgi wrapper
[22:54] <Tv> joshd: still spinning up a cluster to test
[22:54] <Tv> i'm getting a lot of these, that weren't there before:
[22:54] <Tv> INFO:orchestra.run.err:2011-07-05 13:54:12.317259 7f14628b8720 Errors while parsing config file!
[22:54] <Tv> INFO:orchestra.run.err:2011-07-05 13:54:12.317369 7f14628b8720 read_conf: failed to open '/etc/ceph/ceph.conf': error 2: No such file or directory
[22:54] <Tv> INFO:orchestra.run.err:2011-07-05 13:54:12.317374 7f14628b8720 read_conf: failed to open '~/.ceph/config': error 2: No such file or directory
[22:54] <Tv> INFO:orchestra.run.err:2011-07-05 13:54:12.317378 7f14628b8720 read_conf: failed to open 'ceph.conf': error 2: No such file or directory
[22:57] <Tv> execve("/tmp/cephtest/binary/usr/local/bin/radosgw", ["/tmp/cephtest/binary/usr/local/b"..., "-c", "/tmp/cephtest/ceph.conf"], ["PWD=/tmp/cephtest/apache/htdocs"]) = 0
[22:57] <cmccabe> tv: I don't think rgw can function without ceph.conf
[22:57] <Tv> joshd: none of the apache SetEnvs go into the fastcgi environment
[22:58] <cmccabe> tv: at very least, it needs to know what monitors and osds to start talking to, and that's in the conf
[22:58] <Tv> cmccabe: that's well before rgw
[22:58] <joshd> Tv: I guess the example config I saw was wrong then
[22:59] <cmccabe> tv: If you want to put the ceph.conf in a nonstandard location, you can set the CEPH_CONF environment variable
[22:59] <cmccabe> tv: alternately, you can pass -c <ceph-conf-path> on the command line of nearly every program
[22:59] <Tv> cmccabe: I. Know. That.
[22:59] <Tv> cmccabe: i'm saying the behavior changed from work to work but spam errors
[23:00] * nolan (~nolan@phong.sigbus.net) Quit (Ping timeout: 480 seconds)
[23:00] <Tv> that seems to come from cauthtool --create-keyring foo
[23:01] <Tv> which has no use for the config file as far as i know
[23:02] <cmccabe> tv: some of the auth stuff requires a CephContext
[23:02] <Tv> verified, that's from cauthtool --create-keyring foo
[23:03] <Tv> or just about any low-level operation that really does not need the config for anything
[23:03] <cmccabe> tv: ah, yes, it needs the conf so it can get the configured time offset to add to ceph_clock_now
[23:04] <cmccabe> tv: which will be stored into class CryptoKey, which later gets encoded and saved to disk
[23:07] <Tv> that causes 92 lines of errors on every teuthology run now
[23:08] <cmccabe> tv: cauthtool.cc did get marked with CINIT_FLAG_NO_DEFAULT_CONFIG_FILE, so maybe it shouldn't complain if it can't find the conf
[23:09] <cmccabe> tv: I think on balance it should not complain in that situation, seeing as that flag was set.
[23:09] <cmccabe> tv: will fix in a moment.
[23:11] <Tv> joshd: i wonder how rgw *ever* worked for you without SetEnv CEPH_ARGS "-c /tmp/cephtest/ceph.conf"
[23:11] <cmccabe> it is a good question.
[23:12] <Tv> oh
[23:12] <Tv> exec /tmp/cephtest/binary/usr/local/bin/radosgw -c /tmp/cephtest/ceph.conf
[23:12] <Tv> so that setenv is superfluous
[23:14] <joshd> Tv: I think the only one we need is LD_LIBRARY_PATH
[23:15] <joshd> I'm still confused how sepia86 found librgw
[23:18] * nolan (~nolan@phong.sigbus.net) has joined #ceph
[23:18] <Tv> joshd: yeah i see no evidence of that box ever having the ceph debs installed
[23:24] * gregorg_taf (~Greg@78.155.152.6) has joined #ceph
[23:24] * gregorg (~Greg@78.155.152.6) Quit (Read error: Connection reset by peer)
[23:25] <cmccabe> tv: the library build changed a bit with the conversion from using .a everywhere to using .la
[23:26] <cmccabe> tv: the final situation is that we use .a only if we can prove that nobody outside of ceph will ever use a library (i.e. it's just a "convenience library")
[23:26] <cmccabe> tv: I originally wanted to use .la for every library, because that's what the libtool documentation seems to encourage you to do, but sage pointed out that libtool was building dynamic versions of everything even when the dynamic versions were unused.
[23:27] <cmccabe> tv: however, as long as we continue to use libtool, librgw needs to be a .la because we want a shared version to be installed and used.
[23:28] <cmccabe> tv: obsync uses librgw.so, so obviously building librgw.so is a desirable goal :)
[23:28] <Tv> cmccabe: i'm not sure how this is at all related to passing LD_LIBRARY_PATH correctly
[23:28] <cmccabe> tv: the point is, I think perhaps librgw was formerly merged into rgw, and not used as a .so
[23:29] <Tv> perhaps, the exec ... -c ... would explain why it didn't need that env var either
[23:29] <cmccabe> tv: yes, the -c does explain that
[23:32] <cmccabe> I haven't really thought through all the issues related to linking
[23:32] <cmccabe> theoretically, we could build a completely static ceph build where the binaries didn't depend on the libraries we create
[23:33] <cmccabe> we could also make every convenience library dynamic
[23:33] <cmccabe> libtool's approach seems to be somewhere in the middle... libraries that are noinst_LTLIBRARIES (i.e. not installed using make install) get linked in statically, but libraries that are lib_LTLIBRARIES (installed with make install, packaged in make dist, etc.) get used dynamically
[23:34] <Tv> it'd be hard to dynlink noinst libs..
[23:35] <cmccabe> tv: yeah, that's more or less a given
[23:35] <Tv> the lib case is the usual argument for sharing memory mappings
[23:35] <cmccabe> tv: although I wouldn't put it past libtool to come up with some horrible solution involving a secret .libs directory
[23:35] <cmccabe> tv: but it seems that in this case they did not.
[23:36] <cmccabe> tv: shared memory mappings are a nice thing. I suspect there's at least a small build time advantage too
[23:36] <cmccabe> tv: you might laugh, but the linker can take a long long time on C++ because of the weak symbols and so forth
[23:36] <Tv> that's not a good argument for shlibs making it any faster..
[23:37] <cmccabe> with shared libraries, the linking is done at runtime when the program starts.
[23:37] <cmccabe> or when dlopen is called.
[23:37] <Tv> shlibs have lots of complexity on multiple levels
[23:37] <Tv> but anyway, let's work on some bugs or something
[23:40] * u3q (~ben@jupiter.tspigot.net) has joined #ceph
[23:42] <Tv> sagewk, *: do we provide any kernel debs?
[23:43] <sagewk> nope
[23:43] <sagewk> there was some partial work a while back to make a package with the backport module, but never completed
[23:43] <Tv> ok
[23:43] <sagewk> and the backport isn't maintained currently
[23:45] <sagewk> joshd, tv: a bunch of the sepia machines had the ceph package a while back from sam's testing.
[23:45] <Tv> sagewk: i looked through sudo logs and didn't see that on joshd's machine, but it's still a possibility
[23:46] <Tv> cmccabe's theory of rgw being statically linked earlier sounds more likely at this point

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