#ceph IRC Log

Index

IRC Log for 2011-06-27

Timestamps are in GMT/BST.

[0:27] * Juul (~Juul@port80.ds1-vo.adsl.cybercity.dk) Quit (Quit: Leaving)
[0:41] * verwilst_ (~verwilst@dD576703C.access.telenet.be) Quit (Quit: Ex-Chat)
[1:17] * bchrisman (~Adium@c-98-207-207-62.hsd1.ca.comcast.net) has joined #ceph
[2:13] * sugoruyo (~george@athedsl-408632.home.otenet.gr) Quit (Quit: sugoruyo)
[2:47] * yoshi (~yoshi@p24092-ipngn1301marunouchi.tokyo.ocn.ne.jp) has joined #ceph
[4:57] * djlee (~dlee064@des152.esc.auckland.ac.nz) Quit (Quit: Ex-Chat)
[4:57] * jeffhung (~jeffhung@60-250-103-120.HINET-IP.hinet.net) has joined #ceph
[4:57] * jeffhung_ (~jeffhung@60-250-103-120.HINET-IP.hinet.net) Quit (Read error: Connection reset by peer)
[5:08] * jeffhung (~jeffhung@60-250-103-120.HINET-IP.hinet.net) Quit (Ping timeout: 480 seconds)
[5:25] * jeffhung (~jeffhung@60-250-103-120.HINET-IP.hinet.net) has joined #ceph
[6:20] * yehudasa (~yehudasa@ip-66-33-206-8.dreamhost.com) Quit (Read error: Operation timed out)
[6:21] * sjust (~sam@ip-66-33-206-8.dreamhost.com) Quit (Ping timeout: 480 seconds)
[6:21] * gregaf (~Adium@ip-66-33-206-8.dreamhost.com) Quit (Ping timeout: 480 seconds)
[6:22] * gregaf (~Adium@ip-64-111-111-107.dreamhost.com) has joined #ceph
[6:22] * sagewk (~sage@ip-66-33-206-8.dreamhost.com) Quit (Ping timeout: 480 seconds)
[6:22] * yehudasa (~yehudasa@ip-64-111-111-107.dreamhost.com) has joined #ceph
[6:22] * sjust (~sam@ip-64-111-111-107.dreamhost.com) has joined #ceph
[6:23] * sagewk (~sage@ip-64-111-111-107.dreamhost.com) has joined #ceph
[8:10] * votz (~votz@pool-72-78-219-167.phlapa.fios.verizon.net) has joined #ceph
[9:52] * lidongyang__ (~lidongyan@222.126.194.154) has joined #ceph
[9:53] * lidongyang_ (~lidongyan@222.126.194.154) Quit (Write error: connection closed)
[10:09] * Hugh (~hughmacdo@soho-94-143-249-50.sohonet.co.uk) Quit (Quit: Ex-Chat)
[10:25] * sugoruyo (~george@athedsl-318163.home.otenet.gr) has joined #ceph
[10:44] * Yulya_ (~Yu1ya_@ip-95-220-228-250.bb.netbynet.ru) has joined #ceph
[10:51] * jim (~chatzilla@astound-69-42-16-6.ca.astound.net) has joined #ceph
[11:04] * jbd (~jbd@ks305592.kimsufi.com) has left #ceph
[11:07] * jbd (~jbd@ks305592.kimsufi.com) has joined #ceph
[11:08] * yoshi (~yoshi@p24092-ipngn1301marunouchi.tokyo.ocn.ne.jp) Quit (Remote host closed the connection)
[11:14] * Hugh (~hughmacdo@soho-94-143-249-50.sohonet.co.uk) has joined #ceph
[11:53] * darktim (~andre@ticket1.nine.ch) has joined #ceph
[12:15] * sugoruyo (~george@athedsl-318163.home.otenet.gr) Quit (Read error: Connection reset by peer)
[12:17] * sugoruyo (~george@athedsl-318163.home.otenet.gr) has joined #ceph
[13:59] * mtk (~mtk@ool-182c8e6c.dyn.optonline.net) has joined #ceph
[15:04] <sugoruyo> can somebody explain these sort of messages:
[15:04] <sugoruyo> [60064.295926] ceph: try_read bad con->in_tag = 48
[15:04] <sugoruyo> [60064.295942] ceph: osd4 10.254.254.30:6801 protocol error, garbage tag
[15:04] <sugoruyo> [60213.615605] ceph: get_reply unknown tid 168109 from osd4
[15:39] * aliguori (~anthony@32.97.110.65) has joined #ceph
[16:04] * jbd (~jbd@ks305592.kimsufi.com) has left #ceph
[16:12] * jbd (~jbd@ks305592.kimsufi.com) has joined #ceph
[16:47] * yoshi (~yoshi@KD027091032046.ppp-bb.dion.ne.jp) has joined #ceph
[16:55] * yoshi (~yoshi@KD027091032046.ppp-bb.dion.ne.jp) Quit (Remote host closed the connection)
[17:09] * aliguori (~anthony@32.97.110.65) Quit (Ping timeout: 480 seconds)
[17:17] * aliguori (~anthony@32.97.110.64) has joined #ceph
[17:36] * greglap (~Adium@cpe-76-170-84-245.socal.res.rr.com) Quit (Quit: Leaving.)
[17:42] * lxo (~aoliva@09GAAE581.tor-irc.dnsbl.oftc.net) Quit (Read error: Connection reset by peer)
[17:50] * bchrisman (~Adium@c-98-207-207-62.hsd1.ca.comcast.net) Quit (Quit: Leaving.)
[17:51] * greglap (~Adium@166.205.141.48) has joined #ceph
[17:54] <greglap> sugoruyo: hmm, some kind of communication problem between the OSD and the client
[17:55] <sugoruyo> yeah, i was copying 10000 0-byte files to it, and at some point it just hung for a while
[17:56] <sugoruyo> and then completed the job
[17:56] <greglap> hmm
[17:56] <sugoruyo> i also got some similar errors when running csyn --syn rw for a 50 gig file with 4k blocks
[17:57] <greglap> each message they send has a unique "tid" (transaction id) and a tag saying what kind of message it is, so the kclient messenger is saying that those don't make sense, but there are a lot of potential causes for that
[17:58] <sugoruyo> after the write completed the read went through a few normal reads and then went nuts churning out a huge amount of error messages about the data being wrong, the file offset being wrong etc,
[17:58] <sugoruyo> i'm now having a different problem, i tried to delete those 10,000 0-byte files
[18:00] <sugoruyo> of course rm won't take a * so i had to run find -delete, find on its own went fast enough, but after 45' the find -delete hadn't finished so i killed it, but know anything i try regarding the f/s just hangs
[18:00] <sugoruyo> a simple ls that should return 2 results is running 7 minutes now
[18:00] <greglap> yeah, if the FS isn't working ls is going to be slow as hell
[18:01] <greglap> what versions of everything are you running?
[18:01] * darktim (~andre@ticket1.nine.ch) Quit (Remote host closed the connection)
[18:01] <sugoruyo> ceph version 0.29.1 (commit:77d38e420baa604f34298875129c14867dbedaa4), what other version should i check?
[18:01] <greglap> what kernel client are you using?
[18:02] <sugoruyo> how do i check for that?
[18:02] <greglap> if you didn't build it from source, which kernel is it :)
[18:03] <sugoruyo> 2.6.35-28-generic #50-Ubuntu SMP x86_64
[18:04] <greglap> okay
[18:05] * Tv (~Tv|work@ip-64-111-111-107.dreamhost.com) has joined #ceph
[18:06] <greglap> I suspect you ran into some bugs in the kernel client, but if you want to create a bug we'll look into it a bit more :)
[18:07] <sugoruyo> what do you mean if i want to create a bug?
[18:07] <greglap> a bug report in our tracker
[18:07] <greglap> tracker.newdream.net
[18:10] <sugoruyo> what bugs me is there are no other error messages - haven't checked any logs yet tho - dmesg doesn't report anything, all cmds, cmon, cosd processes are running fine, ceph -w output is normal
[18:10] <sugoruyo> it's just hung there like that.
[18:10] <greglap> yeah, that makes me think it's a kernel client bug, but I don't know the progress of the kernel well enough to know for sure
[18:12] <sugoruyo> on a different matter: is there a way to configure it so my mds daemons are all active when i start it?
[18:12] <greglap> you need to set the max_mds
[18:12] <greglap> I think ceph set_max_mds n
[18:12] <greglap> it's in the wiki somewhere, let me see...
[18:13] <sugoruyo> i also ran mkcephfs with a custom map, with customised weights but none of them appears weighted when i run ceph osd dump
[18:13] <greglap> "ceph mds set_max_mds N"
[18:13] <greglap> where N is the number of MDSes you want to have
[18:13] <greglap> if you're following the instructions in the wiki correctly, I dunno
[18:14] <sugoruyo> yeah that's the command for after the system is started, i was asking if i can do it with the conf file
[18:14] <greglap> you'll have to get sagewk's attention for that
[18:14] <greglap> ah, no, not from the config file (yet, at least)
[18:14] <sugoruyo> greglap: about the map, i ran crushtool to build an initial map as per the wiki, customised some rules and the weights, ran crushtool -c on it and passed that to mkcephfs with the --crushmap option
[18:15] <sugoruyo> should the map file be on all nodes like the ceph.conf file?
[18:15] <sagewk> sugoruyo: there are two "weights".. one in the crush map (ceph osd getcrushmap -o /tmp/cm ; crushtool -d /tmp/cm to verify), the other is what you see from ceph osd dump -o -
[18:16] <greglap> no, I don't think you need to distribute the map file
[18:16] <sagewk> the latter should always be 1.0 unless you are correcting for some statistical imbalance, misbehaving node, etc... consider it more like 'partial failure'
[18:17] <sugoruyo> sagewk: what's the difference? i have various sizes of disks and i had this problem where one disk filled up and i couldn't do any writes, so i reweighted them to have more data go into the bigger disks
[18:17] <sugoruyo> sagewk: ceph osd reweight changes the latter correct?
[18:18] <sagewk> sugoruyo: you should set the crush weights based on how much data you want each node to get (disk size). if one node is temporarily overfull, or the temporarily failing, you can adjust its allocation down with the osd weight.
[18:19] <sugoruyo> sagewk: is there a way for me to verify that the correct crush weights are being used?
[18:19] <sagewk> ceph osd getcrushmap -o /tmp/cm ; crushtool -d /tmp/cm
[18:20] <sugoruyo> hmm, those look good
[18:26] <sugoruyo> out of curiosity, does ceph store any stuff other than the usual in a file's inode?
[18:27] <sagewk> less than the usual.. there's no block layout metadata, since the dat object names are deterministic (ino.blocknum)
[18:27] <jim> sugoruyo: that would be an interesting question for #btrfs, but if you mention the word VFS they might jump you.
[18:28] <sagewk> sugoruyo: is the ls is hanging it sounds a problem with the mds lock. a 'ceph mds tell 0 dumpcache /tmp/foo' might have something interesting if you grep out the directory name
[18:29] <sugoruyo> sagewk: well since then, i killed the ls and restarted the whole thing
[18:30] <sugoruyo> the MDSs went through recovery and the OSDs are cleaning up some degradation...
[18:31] <sugoruyo> 2011-06-27 19:29:50.023121 pg v5504: 1188 pgs: 46 active, 1142 active+clean; 51267 MB data, 106 GB used, 176 GB / 297 GB avail; 1353/25740 degraded (5.256%)
[18:31] <sugoruyo> 2011-06-27 19:29:50.031237 mds e48: 3/3/3 up {0=1=up:active,1=0=up:active,2=2=up:active}
[18:32] <sugoruyo> can someone tell me what the 0=1= parts on the left of up:active status for the MDSs mean?
[18:33] <sagewk> the first number is the rank the daemon is filling (always start at 0). the second is the name you gave it in ceph.conf (you used numbers it looks like; i'd recomment abc or something along those lines to avoid confusion, tho it doesn't actually matter)
[18:33] <sagewk> up:active is healthy
[18:34] <sugoruyo> sagewk: yeah, that has me confused since day one...
[18:35] <sugoruyo> if i'd named the damn things i'd have figured it out on my own...
[18:35] <sugoruyo> the dumpcache command should output something?
[18:38] <sagewk> no it just tells the mds to dump to a file. if htat ls isn't hanging anymore tho don't bother
[18:38] <sugoruyo> that ls has long gone to meet its maker
[18:39] <sugoruyo> sagewk: the dumpcache command outputs to a specific file or does it work just like the other commands?
[18:41] <sugoruyo> i have another command that's hanging: find . -type f -delete in a file with 10k 0-byte files
[18:41] <sugoruyo> ps reports its in D+ = uninterruptible sleep... looks like it's waiting for something :S
[18:41] * greglap (~Adium@166.205.141.48) Quit (Read error: Connection reset by peer)
[18:42] * aliguori (~anthony@32.97.110.64) Quit (Read error: Connection reset by peer)
[18:48] * bchrisman (~Adium@70-35-37-146.static.wiline.com) has joined #ceph
[18:54] * aliguori (~anthony@32.97.110.65) has joined #ceph
[18:57] <sagewk> it's ceph mds tell 0 dumpcache <filename>
[18:58] <sagewk> and the file is written on the host the cmds instance is running on
[19:02] <sugoruyo> sagewk: so that dumps an MDSs whole cache?
[19:02] <sagewk> yeah
[19:02] * jbd (~jbd@ks305592.kimsufi.com) has left #ceph
[19:03] <sugoruyo> ok cool, that might help in similar situations
[19:05] * cmccabe (~cmccabe@208.80.64.174) has joined #ceph
[19:07] <sugoruyo> ok i'm getting the hanging find thing again
[19:08] * joshd (~joshd@ip-64-111-111-107.dreamhost.com) has joined #ceph
[19:22] <jim> sugoruyo: are you on usb by chance?
[19:22] <sugoruyo> nope
[19:23] <sugoruyo> find . -type f returns almost instantly on 10,000 empty files, but with -delete it just hangs
[19:23] <jim> i notice my usb3 drive checks out in usb3 mode but works with many fewer power drop outs in usb 2 mode.
[19:23] <sugoruyo> i'm using ls -1 | xargs rm to delete the stuff
[19:23] <jim> what's the important of syncronous delete?
[19:24] <jim> 10000 empty files is cheap to rename elsewhere and clean later.
[19:24] <jim> I would use tmpfs
[19:24] <jim> you can dispose of the whole mess
[19:26] <sugoruyo> jim: i don't understand what you're asking
[19:26] <sugoruyo> i made 10,000 empty files as a test, because i've been having these kind of problems
[19:27] <sugoruyo> so i want to delete them now and move on...
[19:27] <jim> what happens with 10 ? 100 ?
[19:28] <sugoruyo> it's kinda slow but it works
[19:28] <sugoruyo> i don't know at which point it starts to hang
[19:40] * greglap (~Adium@ip-64-111-111-107.dreamhost.com) has joined #ceph
[19:55] * jbd (~jbd@ks305592.kimsufi.com) has joined #ceph
[20:16] * tjikkun (~tjikkun@2001:7b8:356:0:204:bff:fe80:8080) has joined #ceph
[20:30] * lxo (~aoliva@1RDAAABRL.tor-irc.dnsbl.oftc.net) has joined #ceph
[20:32] <bchrisman> how do different crushmap pools interact? Do they all basically have access to all OSD space? ie, do we have competition between a ceph filesystem and a bunch of rbd devices for space? Is there a programmatic interface to track which pool is using how much space?
[20:35] <bchrisman> also, I've assumed that rbd will thin-provision (effectively sparse file on the underlying osd data dir).. I know there's no way to evaluate the actual data blocks used by a sparse file in ceph, but can we get the actual blocks in use for an rbd device?
[20:38] <stingray> rados df
[20:47] * lxo (~aoliva@1RDAAABRL.tor-irc.dnsbl.oftc.net) Quit (Read error: Connection reset by peer)
[20:48] <joshd> bchrisman: I don't think there's a good way to get the actual blocks used for a given rbd image
[20:48] * lxo (~aoliva@1RDAAABSD.tor-irc.dnsbl.oftc.net) has joined #ceph
[20:55] * lxo (~aoliva@1RDAAABSD.tor-irc.dnsbl.oftc.net) Quit (Read error: Connection reset by peer)
[20:55] * lxo (~aoliva@186.214.53.147) has joined #ceph
[20:59] * lxo (~aoliva@186.214.53.147) Quit (Read error: Connection reset by peer)
[20:59] * lxo (~aoliva@186.214.53.147) has joined #ceph
[21:02] <joshd> bchrisman: pools are just a namespace at the rados level - you can have rbd images in the data pool, or assign an inode in the FS to the rbd pool if you want
[21:02] * lxo (~aoliva@186.214.53.147) Quit (Read error: Connection reset by peer)
[21:02] * lxo (~aoliva@186.214.53.147) has joined #ceph
[21:05] * lxo (~aoliva@186.214.53.147) Quit (Read error: Connection reset by peer)
[21:05] * lxo (~aoliva@186.214.53.147) has joined #ceph
[21:06] <joshd> bchrisman: you can get pool usage from librados with rados_ioctx_pool_stat
[21:07] <bchrisman> ahh okay.. so there's an api through which we can get the distribution of space used 'by pool'.. thanks joshd
[21:08] <gregaf> bchrisman: you sent us a patch last month for testceph that included some commented-out calls to closedir?
[21:10] <bchrisman> hmm??? didn't intend to.. I must've screwed somethign up on that??? but yeah.. I was seeing segfaults in closedir that we've verified no longer exist. I think we were calling closedir on a non-existent directory handle.
[21:10] * lxo (~aoliva@186.214.53.147) Quit (Read error: Connection reset by peer)
[21:11] * lxo (~aoliva@186.214.53.147) has joined #ceph
[21:12] <gregaf> heh, okay
[21:12] <gregaf> colin was reporting a bug with uclient and I was trying to figure out why these inodes were still in cache with only one ref apiece and no caps...
[21:12] <gregaf> and sage goes "hmm, it's calling opendir and not closedir"
[21:12] <gregaf> *smacks forehead*
[21:13] * lxo (~aoliva@186.214.53.147) Quit (Read error: Connection reset by peer)
[21:13] * lxo (~aoliva@186.214.53.147) has joined #ceph
[21:14] <bchrisman> I'd think it should be cleaned up on process exit??
[21:14] <cmccabe> heh
[21:15] <cmccabe> bchrisman: I'm not sure exactly what happens on process exit with libceph right now
[21:16] <cmccabe> bchrisman: I actually don't think we register any atexit handlers, so I would guess nothing special?
[21:16] * lxo (~aoliva@186.214.53.147) Quit (Read error: Connection reset by peer)
[21:16] <bchrisman> ahh??? testceph calls shutdown I think??? but yeah.. shutdown should be called??? but even then, a kill ???9 shouldn't cause problems for the filesystem.
[21:16] <Tv> you mean MUST NOT
[21:16] <cmccabe> bchrisman: yes. in general, the process can always get SIGKILL
[21:16] * lxo (~aoliva@186.214.53.147) has joined #ceph
[21:17] <cmccabe> bchrisman: also registering magical handlers to do stuff at process exit is usually considered impolite. It's really up to the caller to do that if he wants.
[21:17] <bchrisman> Tv: agreed??? :) though I was commenting on expected functionality versus actual functionality, whereas MUST NOT is quite aspirational :)
[21:17] <Tv> state of current code has no effect on requirements ;)
[21:18] <cmccabe> bchrisman: tv is referring to the usual meaning of must vs. should in standardese
[21:18] <bchrisman> so if opendir without closedir is causing an undesirable leftover state in the fs??? then yeah.. something needs to figure out how to clean up.
[21:18] <cmccabe> bchrisman: it's actually somewhat important in POSIX
[21:19] * lxo (~aoliva@186.214.53.147) Quit (Read error: Connection reset by peer)
[21:19] <cmccabe> bchrisman: the problem we were discussing is just that testceph was hanging in ceph_unmount
[21:19] <bchrisman> ahh
[21:20] <cmccabe> bchrisman: it's pretty harmless, but it is annoying for libceph users
[21:20] * lxo (~aoliva@186.214.53.147) has joined #ceph
[21:21] <bchrisman> yeah??? so is unmount going to close everything, or is it a libceph developer requirement to closedir anything opendir'd?
[21:21] * lxo (~aoliva@186.214.53.147) Quit (Read error: Connection reset by peer)
[21:21] * lxo (~aoliva@186.214.53.147) has joined #ceph
[21:22] <cmccabe> bchrisman: I sort of got the impression that ceph unmount would hang until nobody was using the filesystem any more
[21:23] <cmccabe> bchrisman: similar to regular unmount
[21:23] <bchrisman> yup.
[21:23] <cmccabe> bchrisman: as far as I know, that's still the goal
[21:23] * lxo (~aoliva@186.214.53.147) Quit (Read error: Connection reset by peer)
[21:23] <Tv> bchrisman: if we're talking about kclient or cfuse, and not libceph, when a process dies, all its file descriptors are closed
[21:23] <Tv> fwiw regular unmount bails out with error when the fs is busy, does not hang
[21:23] <gregaf> you know, we actually added a hack to unmount that closes open file descriptors ??? dunno if that's legit or not
[21:24] <gregaf> no similar hack exists for directories
[21:24] * lxo (~aoliva@186.214.53.147) has joined #ceph
[21:24] <bchrisman> ahh yeah...
[21:24] <cmccabe> gregaf: in my opinion, that should be optional behavior that the user has to request
[21:24] <Tv> gregaf: there's been talks of a "badfs" that umount -f(orce) would re-target open fd's to, but last i tried that code did not work
[21:24] <bchrisman> well with a library filesystem, I imagine it's more difficult to determine what's legit.
[21:24] <cmccabe> gregaf: some kind of super-secret nonstandard -f flag
[21:24] <cmccabe> gregaf: in libeceph probably just an int with flags
[21:25] <Tv> umount has the -f option already, it's just not very useful
[21:25] <cmccabe> tv: well, I mean that ceph_unmount could take a flags argument that could do pretty much whatever we want
[21:25] <cmccabe> tv: but the standard behavior should be the usual block-until-all-references-are-dropped
[21:25] <bchrisman> hmm.. though libceph actually provide ceph_shutdown rather than unmount.. so I think it'd probably be okay to do a cleanup there?
[21:25] <Tv> umount(8) takes no args
[21:26] <cmccabe> tv: I'm talking about libceph man
[21:26] <gregaf> oh right, I switched it to do that because we'd previously had an assert that all files were closed, and obviously that wasn't right...
[21:26] <gregaf> nobody looked into the standard or anything though, that I recall
[21:26] <Tv> bchrisman: are we talking about libceph, cfuse or kclient? libceph is something completely different, and unrelated to kernel-level mounts
[21:26] <Tv> ok so libceph
[21:26] * lxo (~aoliva@186.214.53.147) Quit (Read error: Connection reset by peer)
[21:26] <bchrisman> liceph yeah
[21:26] <gregaf> well the hack to close all is in Client::unmount, which is for both cfuse and libceph
[21:26] <Tv> the client exits, the tcp connection is closed, nothing can live further ;)
[21:26] <bchrisman> cuz a libceph process will just hand in ceph_shutdown
[21:27] <bchrisman> err 'hang'
[21:27] * lxo (~aoliva@186.214.53.147) has joined #ceph
[21:27] <cmccabe> I guess it really depends on what libceph library users find the most useful
[21:27] <Tv> bchrisman: so you e.g. forgot to close a file opened for writing via libceph?
[21:27] <cmccabe> right now we just have libceph_shutdown which is pretty forceful
[21:27] <bchrisman> Tv: It was forgetting to close an opendir I think???
[21:28] <Tv> bchrisman: yeah, read-only fds are easier to handle so i'm gonna ignore those
[21:28] <Tv> imagine a writable file opened via libceph, now what if that file is being written to in another thread
[21:28] <Tv> i can see a good argument for the "wait until no longer busy" case
[21:28] <Tv> i mean, if you want abort, you can always just exit
[21:28] <bchrisman> yeah..
[21:29] <bchrisman> then you need to call shutdown asynchronously
[21:29] <bchrisman> that would work.
[21:30] * lxo (~aoliva@186.214.53.147) Quit (Read error: Connection reset by peer)
[21:30] * lxo (~aoliva@186.214.53.147) has joined #ceph
[21:30] <cmccabe> I think we should offer a forceful shutdown and also one that blocks until all pending work is done
[21:30] <cmccabe> i.e. all caps dropped, etc.
[21:32] <cmccabe> anyway it's not hugely important unless a library user wants it
[21:32] <cmccabe> I am kind of annoyed that Client::unmount doesn't have the same semantics as umount(2) though. Maybe we should rename it to avoid confusion.
[21:32] * lxo (~aoliva@186.214.53.147) Quit (Read error: Connection reset by peer)
[21:32] <gregaf> or just fix it?
[21:32] * lxo (~aoliva@186.214.53.147) has joined #ceph
[21:35] * lxo (~aoliva@186.214.53.147) Quit (Read error: Connection reset by peer)
[21:35] * lxo (~aoliva@186.214.53.147) has joined #ceph
[21:40] * lxo (~aoliva@186.214.53.147) Quit (Read error: Connection reset by peer)
[21:41] * lxo (~aoliva@186.214.53.147) has joined #ceph
[21:44] * jbd (~jbd@ks305592.kimsufi.com) has left #ceph
[21:44] * lxo (~aoliva@186.214.53.147) Quit (Read error: Connection reset by peer)
[21:44] * lxo (~aoliva@186.214.53.147) has joined #ceph
[21:45] <bchrisman> are there any known issues with the version reported in ceph -v? I'm getting back something different from what's getting populated into ceph.spec by 'configure'???
[21:48] <gregaf> bchrisman: what are you getting?
[21:48] * lxo (~aoliva@186.214.53.147) Quit (Read error: Connection reset by peer)
[21:48] <bchrisman> 0.24.2 + commit id when I'm looking at 0.28.2
[21:48] * lxo (~aoliva@186.214.53.147) has joined #ceph
[21:49] <bchrisman> was wodnering whether you guys can check quickly on one of your systems..
[21:49] <bchrisman> I don't use ceph -v much??? just noticed a disparity in my environment.
[21:49] <bchrisman> (so I'm wondering whether my packager automation stuff is screwing up, or if ceph -v is hornked)
[21:49] <yehudasa> bchrisman: might be that it's not compiled statically, so it takes it from some other library
[21:50] <yehudasa> hmm.. actually no
[21:51] <bchrisman> if you guys see ceph -v match what you expect, then I'll track it down on my end...
[21:51] * lxo (~aoliva@186.214.53.147) Quit (Read error: Connection reset by peer)
[21:52] <yehudasa> it takes the version from ceph_ver.h
[21:52] <yehudasa> which should be updated whenever .git_version changes
[21:52] * lxo (~aoliva@186.214.53.147) has joined #ceph
[21:52] <yehudasa> :q
[21:52] <yehudasa> whoops
[21:56] * lxo (~aoliva@186.214.53.147) Quit (Read error: Connection reset by peer)
[21:56] * lxo (~aoliva@04ZAAACLB.tor-irc.dnsbl.oftc.net) has joined #ceph
[22:01] * lxo (~aoliva@04ZAAACLB.tor-irc.dnsbl.oftc.net) Quit (Read error: Connection reset by peer)
[22:02] * lxo (~aoliva@83TAAB3SS.tor-irc.dnsbl.oftc.net) has joined #ceph
[22:05] * lxo (~aoliva@83TAAB3SS.tor-irc.dnsbl.oftc.net) Quit (Read error: Connection reset by peer)
[22:06] * lxo (~aoliva@19NAAB3LP.tor-irc.dnsbl.oftc.net) has joined #ceph
[22:08] * lxo (~aoliva@19NAAB3LP.tor-irc.dnsbl.oftc.net) Quit (Read error: Connection reset by peer)
[22:08] <yehudasa> bchrisman: we're generating .git_version apparently
[22:08] * lxo (~aoliva@9YYAABQ0T.tor-irc.dnsbl.oftc.net) has joined #ceph
[22:09] <bchrisman> submitted a bug report.. should be small...
[22:10] <yehudasa> there's a check_version script that is supposed to be called
[22:10] <yehudasa> so either it's not getting called or it fails for some reason
[22:12] <bchrisman> I can take a peek after lunch???
[22:12] * lxo (~aoliva@9YYAABQ0T.tor-irc.dnsbl.oftc.net) Quit (Read error: Connection reset by peer)
[22:13] * lxo (~aoliva@09GAAE6VZ.tor-irc.dnsbl.oftc.net) has joined #ceph
[22:13] * jeffhung (~jeffhung@60-250-103-120.HINET-IP.hinet.net) Quit (Ping timeout: 480 seconds)
[22:15] * lxo (~aoliva@09GAAE6VZ.tor-irc.dnsbl.oftc.net) Quit (Read error: Connection reset by peer)
[22:15] * lxo (~aoliva@83TAAB3S1.tor-irc.dnsbl.oftc.net) has joined #ceph
[22:18] * lxo (~aoliva@83TAAB3S1.tor-irc.dnsbl.oftc.net) Quit (Read error: Connection reset by peer)
[22:18] * lxo (~aoliva@19NAAB3L6.tor-irc.dnsbl.oftc.net) has joined #ceph
[22:20] * jbd (~jbd@ks305592.kimsufi.com) has joined #ceph
[22:21] * lxo (~aoliva@19NAAB3L6.tor-irc.dnsbl.oftc.net) Quit (Read error: Connection reset by peer)
[22:21] * lxo (~aoliva@1RDAAABVM.tor-irc.dnsbl.oftc.net) has joined #ceph
[22:24] * lxo (~aoliva@1RDAAABVM.tor-irc.dnsbl.oftc.net) Quit (Read error: Connection reset by peer)
[22:25] * lxo (~aoliva@19NAAB3MC.tor-irc.dnsbl.oftc.net) has joined #ceph
[22:28] * lxo (~aoliva@19NAAB3MC.tor-irc.dnsbl.oftc.net) Quit (Read error: Connection reset by peer)
[22:29] * lxo (~aoliva@9YYAABQ05.tor-irc.dnsbl.oftc.net) has joined #ceph
[22:37] * lxo (~aoliva@9YYAABQ05.tor-irc.dnsbl.oftc.net) Quit (Read error: Connection reset by peer)
[22:37] * lxo (~aoliva@19NAAB3MM.tor-irc.dnsbl.oftc.net) has joined #ceph
[22:38] * sugoruyo (~george@athedsl-318163.home.otenet.gr) Quit (Remote host closed the connection)
[22:40] * jeffhung (~jeffhung@60-250-103-120.HINET-IP.hinet.net) has joined #ceph
[22:40] * lxo (~aoliva@19NAAB3MM.tor-irc.dnsbl.oftc.net) Quit (Read error: Connection reset by peer)
[22:40] * lxo (~aoliva@9YYAABQ1D.tor-irc.dnsbl.oftc.net) has joined #ceph
[22:42] <cmccabe> bchrisman: it could be an issue with how we're doing libcommon now
[22:43] <cmccabe> but actually, I don't see how...
[22:43] * lxo (~aoliva@9YYAABQ1D.tor-irc.dnsbl.oftc.net) Quit (Read error: Connection reset by peer)
[22:44] <cmccabe> .git_version is a FORCE target, so it should get re-generated each compile
[22:44] * lxo (~aoliva@1RDAAABV9.tor-irc.dnsbl.oftc.net) has joined #ceph
[22:44] <cmccabe> then ceph_ver.h and ceph_ver.c in turn should be generated, which should update libcommon.la
[22:46] <bchrisman> 'git describe' reports v0.24
[22:47] <cmccabe> I am building it now, will see if ceph -v turns out ok
[22:47] <bchrisman> thx
[22:47] <cmccabe> cmccabe@metropolis:~/ceph2/src$ ./ceph -v
[22:47] <cmccabe> ceph version 0.29.1-496-g19614bb (commit:19614bb868124fcb51308f62f7c0cfa13a31038c)
[22:47] <cmccabe> cmccabe@metropolis:~/ceph2/src$ git describe HEAD
[22:47] <cmccabe> v0.29.1-496-g19614bb
[22:48] <bchrisman> alright.. thanks.. something's hosed in the repo then..
[22:48] <cmccabe> then I made a commit, and rebuilt
[22:49] <cmccabe> and ceph -v now reports ceph version 0.29.1-497-gff5b200 (commit:ff5b2000cb2bd3bc378594b714e2eb31b923da79)
[22:49] * lxo (~aoliva@1RDAAABV9.tor-irc.dnsbl.oftc.net) Quit (Read error: Connection reset by peer)
[22:49] <cmccabe> i.e. commit hash has changed
[22:49] * lxo (~aoliva@09GAAE6WR.tor-irc.dnsbl.oftc.net) has joined #ceph
[22:49] <cmccabe> I'm not sure why git-describe would report v0.24
[22:49] <cmccabe> for you
[22:50] <cmccabe> unless you are on a different branch?
[22:52] * lxo (~aoliva@09GAAE6WR.tor-irc.dnsbl.oftc.net) Quit (Read error: Connection reset by peer)
[22:52] <bchrisman> we're keeping a local repo??? so something about the way we're bringing in upstream commits is messed up.
[22:52] * lxo (~aoliva@1RDAAABWK.tor-irc.dnsbl.oftc.net) has joined #ceph
[22:52] <bchrisman> thanks for yer guys' help??? internal git newbie issue here on my part
[22:59] * lxo (~aoliva@1RDAAABWK.tor-irc.dnsbl.oftc.net) Quit (Read error: Connection reset by peer)
[22:59] * lxo (~aoliva@19NAAB3M7.tor-irc.dnsbl.oftc.net) has joined #ceph
[23:02] * lxo (~aoliva@19NAAB3M7.tor-irc.dnsbl.oftc.net) Quit (Read error: Connection reset by peer)
[23:02] * lxo (~aoliva@04ZAAACNH.tor-irc.dnsbl.oftc.net) has joined #ceph
[23:04] * lxo (~aoliva@04ZAAACNH.tor-irc.dnsbl.oftc.net) Quit (Read error: Connection reset by peer)
[23:05] * lxo (~aoliva@9YYAABQ1U.tor-irc.dnsbl.oftc.net) has joined #ceph
[23:06] <bchrisman> ahh, so we pull from newdream git repo and then push to a local repo.. but we weren't putting ???tags on the push??? that fixes my packaging issues.
[23:13] * lxo (~aoliva@9YYAABQ1U.tor-irc.dnsbl.oftc.net) Quit (Read error: Connection reset by peer)
[23:14] * jbd (~jbd@ks305592.kimsufi.com) has left #ceph
[23:14] * lxo (~aoliva@1GLAACIM6.tor-irc.dnsbl.oftc.net) has joined #ceph
[23:19] * lxo (~aoliva@1GLAACIM6.tor-irc.dnsbl.oftc.net) Quit (Read error: Connection reset by peer)
[23:19] * lxo (~aoliva@1GLAACINC.tor-irc.dnsbl.oftc.net) has joined #ceph
[23:26] * lxo (~aoliva@1GLAACINC.tor-irc.dnsbl.oftc.net) Quit (Read error: Connection reset by peer)
[23:27] * lxo (~aoliva@04ZAAACN6.tor-irc.dnsbl.oftc.net) has joined #ceph
[23:46] * aliguori (~anthony@32.97.110.65) Quit (Quit: Ex-Chat)
[23:52] * lxo (~aoliva@04ZAAACN6.tor-irc.dnsbl.oftc.net) Quit (Read error: Connection reset by peer)
[23:53] * lxo (~aoliva@659AACQ94.tor-irc.dnsbl.oftc.net) has joined #ceph
[23:54] <cmccabe> I don't think anyone deletes the C_Gather created in Filer::truncate
[23:55] <cmccabe> well, it looks like it's deleted by the last "sub"-- but nowhere is it guaranteed that there will actually be subs.
[23:58] * lxo (~aoliva@659AACQ94.tor-irc.dnsbl.oftc.net) Quit (Read error: Connection reset by peer)
[23:58] * lxo (~aoliva@19NAAB3N9.tor-irc.dnsbl.oftc.net) has joined #ceph

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