#ceph IRC Log

Index

IRC Log for 2012-02-23

Timestamps are in GMT/BST.

[0:03] * BManojlovic (~steki@212.200.243.83) Quit (Remote host closed the connection)
[0:42] * mtk (~mtk@ool-44c35967.dyn.optonline.net) Quit (Remote host closed the connection)
[0:49] * lofejndif (~lsqavnbok@207.Red-88-19-214.staticIP.rima-tde.net) Quit (Quit: Leaving)
[1:12] * aliguori (~anthony@cpe-70-123-132-139.austin.res.rr.com) Quit (Quit: Ex-Chat)
[1:13] * aliguori (~anthony@cpe-70-123-132-139.austin.res.rr.com) has joined #ceph
[1:39] * yoshi (~yoshi@p8031-ipngn2701marunouchi.tokyo.ocn.ne.jp) has joined #ceph
[1:40] * Tv|work (~Tv__@aon.hq.newdream.net) has joined #ceph
[1:50] * joao (~joao@89-181-147-200.net.novis.pt) Quit (Quit: joao)
[1:50] * tnt_ (~tnt@123.165-67-87.adsl-dyn.isp.belgacom.be) Quit (Ping timeout: 480 seconds)
[1:56] * Tv|work (~Tv__@aon.hq.newdream.net) Quit (Ping timeout: 480 seconds)
[2:15] * aliguori (~anthony@cpe-70-123-132-139.austin.res.rr.com) Quit (Read error: Operation timed out)
[2:28] * chutzpah (~chutz@216.174.109.254) Quit (Quit: Leaving)
[2:53] * bchrisman (~Adium@108.60.121.114) Quit (Quit: Leaving.)
[3:11] * MarkDude (~MT@c-71-198-138-155.hsd1.ca.comcast.net) Quit (Read error: Connection reset by peer)
[3:19] * yehudasa_ (~yehudasa@aon.hq.newdream.net) has joined #ceph
[3:19] * gregaf (~Adium@aon.hq.newdream.net) has joined #ceph
[3:19] * MarkDude (~MT@c-71-198-138-155.hsd1.ca.comcast.net) has joined #ceph
[3:19] * sagewk (~sage@aon.hq.newdream.net) has joined #ceph
[3:20] * joshd1 (~joshd@aon.hq.newdream.net) has joined #ceph
[3:20] * dmick (~dmick@aon.hq.newdream.net) has joined #ceph
[3:21] * sjust1 (~sam@aon.hq.newdream.net) has joined #ceph
[3:23] * gregaf1 (~Adium@aon.hq.newdream.net) has joined #ceph
[3:23] * yehudasa__ (~yehudasa@aon.hq.newdream.net) has joined #ceph
[3:23] * sagewk2 (~sage@aon.hq.newdream.net) has joined #ceph
[3:24] * dmick2 (~dmick@aon.hq.newdream.net) has joined #ceph
[3:24] * yehudasa_ (~yehudasa@aon.hq.newdream.net) Quit (Read error: Operation timed out)
[3:24] * joshd2 (~joshd@aon.hq.newdream.net) has joined #ceph
[3:24] * sagewk (~sage@aon.hq.newdream.net) Quit (Read error: Operation timed out)
[3:25] * sjust2 (~sam@aon.hq.newdream.net) has joined #ceph
[3:25] * joshd1 (~joshd@aon.hq.newdream.net) Quit (Read error: Operation timed out)
[3:25] * yehudasa_ (~yehudasa@aon.hq.newdream.net) has joined #ceph
[3:25] * dmick1 (~dmick@aon.hq.newdream.net) Quit (Ping timeout: 480 seconds)
[3:25] * gregaf1 (~Adium@aon.hq.newdream.net) Quit (Read error: Operation timed out)
[3:25] * gregaf1 (~Adium@aon.hq.newdream.net) has joined #ceph
[3:25] * sjust (~sam@aon.hq.newdream.net) Quit (Ping timeout: 480 seconds)
[3:25] * gregaf2 (~Adium@aon.hq.newdream.net) Quit (Ping timeout: 480 seconds)
[3:25] * joshd (~joshd@aon.hq.newdream.net) Quit (Ping timeout: 480 seconds)
[3:25] * sagewk (~sage@aon.hq.newdream.net) has joined #ceph
[3:26] * yehudasa__ (~yehudasa@aon.hq.newdream.net) Quit (Read error: Operation timed out)
[3:26] * yehudasa (~yehudasa@aon.hq.newdream.net) Quit (Ping timeout: 480 seconds)
[3:26] * sagewk1 (~sage@aon.hq.newdream.net) Quit (Ping timeout: 480 seconds)
[3:26] * sagewk2 (~sage@aon.hq.newdream.net) Quit (Read error: Operation timed out)
[3:27] * gregaf (~Adium@aon.hq.newdream.net) Quit (Ping timeout: 480 seconds)
[3:28] * dmick (~dmick@aon.hq.newdream.net) Quit (Ping timeout: 480 seconds)
[3:29] * sjust1 (~sam@aon.hq.newdream.net) Quit (Ping timeout: 480 seconds)
[4:01] * MarkN (~nathan@142.208.70.115.static.exetel.com.au) Quit (Ping timeout: 480 seconds)
[4:07] * joshd2 (~joshd@aon.hq.newdream.net) Quit (Quit: Leaving.)
[4:32] * MarkN (~nathan@142.208.70.115.static.exetel.com.au) has joined #ceph
[4:34] * lxo (~aoliva@lxo.user.oftc.net) has joined #ceph
[5:07] * dmick2 (~dmick@aon.hq.newdream.net) has left #ceph
[5:41] * bchrisman (~Adium@c-76-103-130-94.hsd1.ca.comcast.net) has joined #ceph
[6:37] <f4m8> Guten morgen zusammen
[7:06] * rcattelan (~cattelan@c-66-41-26-220.hsd1.mn.comcast.net) Quit (Quit: Leaving)
[7:38] * MarkDude (~MT@c-71-198-138-155.hsd1.ca.comcast.net) Quit (Quit: Leaving)
[8:05] * tnt_ (~tnt@123.165-67-87.adsl-dyn.isp.belgacom.be) has joined #ceph
[9:11] * tnt_ (~tnt@123.165-67-87.adsl-dyn.isp.belgacom.be) Quit (Ping timeout: 480 seconds)
[9:24] * tnt_ (~tnt@212-166-48-236.win.be) has joined #ceph
[9:28] * sage (~sage@cpe-76-94-40-34.socal.res.rr.com) Quit (Read error: Operation timed out)
[9:31] * fronlius (~fronlius@testing78.jimdo-server.com) has joined #ceph
[9:49] * sage (~sage@cpe-76-94-40-34.socal.res.rr.com) has joined #ceph
[9:52] * BManojlovic (~steki@91.195.39.5) has joined #ceph
[10:00] * yoshi (~yoshi@p8031-ipngn2701marunouchi.tokyo.ocn.ne.jp) Quit (Remote host closed the connection)
[10:04] <tnt_> yay: "2012-02-23 10:03:54.600082 mon.0 -> 'HEALTH_OK' (0)" :)
[10:09] * sage (~sage@cpe-76-94-40-34.socal.res.rr.com) Quit (Read error: Operation timed out)
[10:21] * sage (~sage@cpe-76-94-40-34.socal.res.rr.com) has joined #ceph
[10:52] * andret (~andre@pcandre.nine.ch) Quit (Ping timeout: 480 seconds)
[11:00] <tnt_> When creating a new pool with 'ceph osd pool create XXX', the owner appears as 18446744073709551615 in 'ceph osd dump', which seems a bit weird.
[11:16] <Olivier_bzh> Hello everybody !
[11:17] <Olivier_bzh> I would just like to report that my upgrade from 0.41 to 0.42 succeeded
[11:39] <tnt_> what are "pg_num 192 pgp_num 192 lpg_num 0 lpgp_num 0 " ? when I create pool myself, it's different that from the "default" pools and tough I can set pgp_num and pg_num, I don't find anything about lg_num and lgp_num.
[11:42] * joao (~joao@89.181.147.200) has joined #ceph
[12:11] * lofejndif (~lsqavnbok@207.Red-88-19-214.staticIP.rima-tde.net) has joined #ceph
[12:52] * wi3dzma (3eb503c8@ircip3.mibbit.com) has joined #ceph
[12:55] <tnt_> Is there a debug command to see how a file was distributed among osd ? cephfs show_location/show_layout don't print out how it's been replicated AFAICT.
[13:06] <wido> tnt_: you want to know where a file ended up?
[13:07] <wido> tnt_: A file gets placed into a placement group (pg) and the pg is assigned to a couple of OSD's
[13:07] <wido> ceph pg dump -o -|grep <your pg>
[13:07] <wido> that will show you where a pg is stored
[13:16] <tnt_> wido: ah yes I see. Anyway to map a file (or object.name) to a pg ?
[13:18] * andret (~andre@pcandre.nine.ch) has joined #ceph
[13:18] <wido> tnt_: A file gets split into multiple objects and each object will/can get into a different pg
[13:18] <wido> I don't work with the filesystem that often, so I'm not sure how to map a file to a object and pg
[13:19] <tnt_> Yes, with cephfs I see how to get the various "object name" that correspond to the various blocks the file has been divided in. Now I need to map those to a pg.
[13:26] * lofejndif (~lsqavnbok@207.Red-88-19-214.staticIP.rima-tde.net) Quit (Quit: Leaving)
[13:34] * semekh (~semekh@77.237.181.226) has joined #ceph
[13:36] <semekh> I am testing Ceph, but I feel it's a little bit slow. Currently, I have 2 servers in the cluster, and they're providing 70MB/s total data transfer. (while a simple copy/paste provides 130MB/s) am I missing a point?
[13:45] <wido> semekh: It's hard to say. Are you using journals on your OSD's?
[13:45] <wido> Running a recent version of btrfs?
[13:45] <wido> Ceph is still under development so improvements are made every day
[13:46] <wido> not everything has been worked out yet and tested, 'best practices' are not available yet
[13:46] <wido> 2 servers however should work, but you probably won't get the highest performance.
[13:47] <wido> The way I see Ceph is that in a single operation it will provider a good/medium performance, but it's awesomeness comes around the corner when you start to scale and start running multiple parallel threads
[13:47] <wido> Due to the replication between the OSD's you will always face a bottleneck of one OSD
[13:48] <semekh> Good to see someone's heree :D
[13:48] <semekh> Yes, I am using btrfs
[13:48] <semekh> and am using the latest kernel
[13:48] <semekh> (3.3)
[13:49] <semekh> So, should I expect an increase in data throughput with 2 osds?
[13:51] * mtk (~mtk@ool-44c35967.dyn.optonline.net) has joined #ceph
[13:51] <wido> semekh: No, since you write to the first OSD and that has to replicate to the second
[13:51] <wido> but if for example you have 100 OSD's and you run a copy that single copy will be limited to the performance of a single OSD.
[13:52] <wido> when you start a second one, that second one will be handeld by a different set of OSD's, thus giving you the same performance again
[13:53] <wido> If you have three OSD's and your replication level is set to 3 you will have to write to three OSD's before the write is complete
[13:53] <wido> The replication takes time and will cost you some performance
[13:54] <wido> But, I got to go, I'm afk
[13:57] * semekh (~semekh@77.237.181.226) Quit (Quit: Leaving)
[14:03] * aliguori (~anthony@cpe-70-123-132-139.austin.res.rr.com) has joined #ceph
[14:40] <tnt_> I'm running a few scenarios to see how cephs react and how to deal with various situations. Here I have data stored on a pool that had a replaction of 1 (i.e. no replication) and I simulated the lost of a HDD (shut down osd, reformat it it and restart it).
[14:40] <tnt_> Now obviously I've lost data (which I expect), and 'ceph health' says 'HEALTH_WARN 83 pgs stale'
[14:40] <tnt_> How can I "cleanup". Like how to delete files that are incomplete now ?
[15:26] * cattelan (~cattelan@c-66-41-26-220.hsd1.mn.comcast.net) has joined #ceph
[15:30] * lofejndif (~lsqavnbok@207.Red-88-19-214.staticIP.rima-tde.net) has joined #ceph
[15:31] * nhorman (~nhorman@nat-pool-rdu.redhat.com) has joined #ceph
[16:39] * MarkDude (~MT@c-71-198-138-155.hsd1.ca.comcast.net) has joined #ceph
[16:53] * aa (~aa@r200-40-114-26.ae-static.anteldata.net.uy) has joined #ceph
[17:05] * aliguori (~anthony@cpe-70-123-132-139.austin.res.rr.com) Quit (Quit: Ex-Chat)
[17:08] <iggy> tnt_: I doubt that's going to be handled by any tools ceph has... I'd imagine the suggestion would be restore from backups
[17:09] <MarkDude> f`1 .
[17:10] <MarkDude> lhyujjjjjjjjjjjjjvf'
[17:10] <darkfader> iggy: he can't have to restore everything because he lost something isolated. but, on the other hand it's like that with every filesystem
[17:11] <darkfader> but it might be interesting to have the chance to "flush" something out
[17:12] <tnt_> iggy: well, the file that I had with replication '1' I don't mind loosing. (they're basically thumbnails, I can recompute them if missing). But I want to tell ceph: "Ok, you lost data, move on ..."
[17:13] <iggy> do you know _any_ other filesystem that will do that?
[17:14] <darkfader> haha! ext3! because it'll not notice you lost it in the first place!
[17:15] <darkfader> but more serious, on most fs one could fire up the fs debugger to do that
[17:15] <darkfader> iggy: can AFS do it? I don't know it but it would be the right scale to compare to
[17:16] <darkfader> i can imagine a ceph fs might live for 10-15 years and span 200 servers or so - there you have a good chance something may happen[tm] over the timespan
[17:17] <darkfader> and while a partial restore is no biggie at all, the "mkfs" means full disruption of service
[17:17] <darkfader> so people would live on with stale items for years to avoid that lol
[17:19] <iggy> I'm not saying it wouldn't be a great feature, but I doubt the tooling has gotten that far yet
[17:19] <darkfader> ah oki
[17:19] <darkfader> i took "going to be handled" as something in the future, but that was wrong
[17:20] <darkfader> right now it's not there and thats just fine i guess
[17:20] <iggy> I mean ceph is still at the point where doing backup/wipe/mkfs/restore is pretty common place
[17:20] <darkfader> yeah
[17:21] <iggy> once people start really relying on ceph, I bet you'll start seeing more features like that
[17:21] <darkfader> tomorrow i'll write the ceph chapter for our storage class, i hope that will get more "$$$$" interest in ceph
[17:22] <darkfader> the sad thing is we have a ssd in every pc but only gigE
[17:22] <darkfader> so i can just show them they have more space
[17:22] <darkfader> but less speed
[17:30] <MarkDude> Sorry folks, cat on the keyboard. This one has found the enter button
[17:32] <joao> MarkDude: consider yourself lucky if he didn't found out how to pull the keys off the keyboard :)
[17:33] <joao> (and what a good scratching pad the keyboard is...)
[17:33] <MarkDude> lol, well this one likes pulling wires during G+ hangouts
[17:34] <joao> that's why cats are so incredibly awesome and annoying at the same time
[17:39] * aliguori (~anthony@32.97.110.59) has joined #ceph
[17:39] * phil_ (~quassel@chello080109010223.16.14.vie.surfer.at) has joined #ceph
[17:41] * lofejndif (~lsqavnbok@207.Red-88-19-214.staticIP.rima-tde.net) Quit (Quit: Leaving)
[17:52] * BManojlovic (~steki@91.195.39.5) Quit (Quit: Ja odoh a vi sta 'ocete...)
[18:01] * wi3dzma (3eb503c8@ircip3.mibbit.com) Quit (Quit: http://www.mibbit.com ajax IRC Client)
[18:07] * aliguori (~anthony@32.97.110.59) Quit (Ping timeout: 480 seconds)
[18:12] * ajnelson_ (~ajnelson@c-98-234-137-2.hsd1.ca.comcast.net) has joined #ceph
[18:13] * phil_ (~quassel@chello080109010223.16.14.vie.surfer.at) Quit (Remote host closed the connection)
[18:18] * aliguori (~anthony@32.97.110.64) has joined #ceph
[18:31] * Tv|work (~Tv__@aon.hq.newdream.net) has joined #ceph
[18:35] <darkfader> are there usuable ceph packages for debian squeeze at the moment?
[18:35] <darkfader> -u
[18:41] * joshd (~joshd@aon.hq.newdream.net) has joined #ceph
[18:45] * tnt_ (~tnt@212-166-48-236.win.be) Quit (Ping timeout: 480 seconds)
[18:46] * ajnelson_ (~ajnelson@c-98-234-137-2.hsd1.ca.comcast.net) Quit (Quit: ajnelson_)
[18:58] * dmick (~dmick@aon.hq.newdream.net) has joined #ceph
[19:00] * ajnelson_ (~ajnelson@dsl-63-249-108-243.static.cruzio.com) has joined #ceph
[19:00] * ajnelson_ (~ajnelson@dsl-63-249-108-243.static.cruzio.com) Quit ()
[19:00] * tnt_ (~tnt@80.63-67-87.adsl-dyn.isp.belgacom.be) has joined #ceph
[19:01] * chutzpah (~chutz@216.174.109.254) has joined #ceph
[19:03] <sagewk> anybody want to glace at wip-dencoder before i merge that?
[19:03] <sagewk> (man page and puts ceph-dencoder in deb and rpms)
[19:03] <pulsar> http://dl.dropbox.com/u/3343578/Capture.PNG - 14gb ram usage for a mds. what options do i have to tweak ram usage when dealing with many many files?
[19:04] <pulsar> other than multiple mds instances which ich what i am going to test now
[19:05] <gregaf1> pulsar: what system are you running on?
[19:05] <pulsar> 0.41 / xfs / debian squeeze
[19:05] <gregaf1> the MDS shouldn't be able to use up that much memory unless you set its cache config settings *really* high
[19:05] <pulsar> i have ~10m files/directories
[19:05] <pulsar> did not touch any cache settings yet
[19:05] <pulsar> pretty much vanilla config
[19:06] <pulsar> one mds, one mon, 76 osds
[19:06] <gregaf1> hrm, what's your largest single directory?
[19:06] <darkfader> pulsar: can you tell me what kernel you're runnign? since that is quite like my question
[19:07] <pulsar> gregaf1: cant say right now, I/O blocking issues
[19:07] * aliguori (~anthony@32.97.110.64) Quit (Read error: Operation timed out)
[19:07] <pulsar> darkfader: darkfader: 2.6.26-2-xen-amd64
[19:07] <pulsar> errrr
[19:07] <pulsar> wait
[19:07] <gregaf1> tnt_: that very large number you saw is −1 interpreted as an unsigned — it's the default "authid" for RADOS stuff and means "unset"
[19:07] <pulsar> darkfader: 2.6.32-5-amd64
[19:07] <darkfader> pulsar: wow ok i didn't think it'd be that easy by now. thanks :)
[19:08] <darkfader> oki
[19:08] <gregaf1> there are analagous commands for setting the lpg[p]_num just like the pg[p]_num ones; though the l prefix stands for "local" and you really shouldn't be using them anyway so 0 is a fine setting
[19:09] <gregaf1> pulsar: actually, you don't have enough files in there to account for 14GB of cache anyway
[19:09] <pulsar> darkfader: max projected subdirecotires per test-node are ~3m
[19:09] <pulsar> errr
[19:09] <pulsar> gregaf1:
[19:10] <pulsar> i have written a simple / small script and let it run for the past 18 hours
[19:10] <pulsar> on 40 machines
[19:11] <joshd> tnt_, darkfader, iggy: there actually is already support for marking data lost: ceph osd lost <id> [--yes-i-really-mean-it]
[19:11] <pulsar> http://dl.dropbox.com/u/3343578/logs/stress.php.txt
[19:11] <pulsar> @gr
[19:12] <pulsar> creates directories / files like crazy
[19:12] <gregaf1> yeah
[19:12] <pulsar> not fancy or anything, stress-testing
[19:12] <gregaf1> that doesn't look like it should be at all painful
[19:12] <pulsar> it is :)
[19:12] <gregaf1> pretty small number of files/subdirs per folder, right?
[19:12] <gregaf1> or am I misreading that
[19:13] <gregaf1> oh, wait, it's 300k in the top-level directory, isn't it
[19:13] <pulsar> max 3m subdirectories
[19:13] <pulsar> 3m
[19:13] <gregaf1> heh, off-by-one, can't read
[19:13] <gregaf1> okay
[19:13] <pulsar> but i did not get even close to that
[19:13] <gregaf1> so I'm surprised you've managed to build up that much memory pressure but it might explain that
[19:13] <pulsar> maybe 10k by now
[19:14] <gregaf1> oh
[19:14] <gregaf1> harrumph, if it was >100k it would make *some* sense
[19:14] <gregaf1> I can give you some options that might make it better but I have to go for a few minutes, be back after our standup
[19:14] <pulsar> one node died somehwhen last night
[19:14] <pulsar> says down+preering
[19:15] <pulsar> 1 down+peering;
[19:15] <pulsar> oh, wait... 3 nodes died by now
[19:15] <pulsar> nodes == osds
[19:17] <pulsar> i could use md5 hashes / nibbles to partition / spread the data more evenly across directories if this would make any difference
[19:18] <tnt_> joshd: Ok. I'll try that tomorrow. And after that I can just recreate a new OSD with the same ID ?
[19:18] * aliguori (~anthony@32.97.110.59) has joined #ceph
[19:22] * nolan (~nolan@phong.sigbus.net) Quit (Quit: ZNC - http://znc.sourceforge.net)
[19:23] * gohko_ (~gohko@natter.interq.or.jp) Quit (Read error: Connection reset by peer)
[19:23] * nolan (~nolan@phong.sigbus.net) has joined #ceph
[19:24] * gohko (~gohko@natter.interq.or.jp) has joined #ceph
[19:32] <joshd> tnt_: I think so
[19:35] <gregaf1> pulsar: well, the down+peering PG is probably why your IO is stuck, and actually it *might* explain your odd MDS memory consumption (although I would have expected it to stop doing anything well before that point)
[19:35] <gregaf1> you should grab whatever evidence you have off your OSDs (backtraces from the logs, any core dumps) and restart them and see if things resolve
[19:37] <pulsar> io pressure did not look that bad on the cluster, although i have at least one node stuck in some sort of io deadlock
[19:38] <pulsar> using fuse btw
[19:38] <gregaf1> pulsar: well a down PG means that some data can't be read or written, and the system doesn't try to avoid down PGs when writing (it can't)
[19:38] <Tv|work> sagewk, *: The crush bug email I mentioned has subject "I found some problem in CRUSH code".. My reading of the code says he is correct, I haven't put in enough time to see what the implications are.
[19:39] <pulsar> shouln't those get reassigned to a new osd?
[19:39] <gregaf1> they should and in fact have been (that's why they're peering)
[19:39] <pulsar> they are peering for hours now :)
[19:39] <gregaf1> but apparently it was stored only on the down nodes so the new OSD can't start up the PG because it doesn't have all the data
[19:39] <pulsar> but.. at this point it is difficult to say what is causing that
[19:40] <sagewk> tv|work: k, i'll take a look
[19:40] <gregaf1> so you have 2 or 3-way replication (I forget which) and you have 3 machines down
[19:40] <gregaf1> there are some PGs which were hosted only on those 3 machines
[19:40] <gregaf1> which means some data cannot be accessed by the other nodes
[19:41] <gregaf1> you will need to bring those OSDs back up at least long enough for all the data to get exported :)
[19:41] <pulsar> can i read over/underreplicated blocks statistics as with hdfs?
[19:41] <pulsar> or query even
[19:41] <gregaf1> ceph pg dump
[19:41] <gregaf1> will tell you the status of each PG
[19:42] <pulsar> version 72841
[19:42] <pulsar> last_osdmap_epoch 233
[19:42] <pulsar> last_pg_scan 1
[19:42] <pulsar> full_ratio 0.95
[19:42] <pulsar> nearfull_ratio 0.85
[19:42] <gregaf1> I'm not sure if it's currently possible to get a look at which blocks specifically are under-replicated
[19:42] <pulsar> and all pgs
[19:42] <gregaf1> well there's going to be an output line for each PG :)
[19:42] <pulsar> yes
[19:42] <gregaf1> if the PG is "clean" that means it's fully replicated
[19:42] <gregaf1> if it's not, it's under-replicated
[19:42] <gregaf1> you can also look at which OSDs are hosting it and which should be hosting it
[19:42] <pulsar> soo peering 0'0 means dead, really dead?
[19:44] <pulsar> ah, down+peering
[19:45] <gregaf1> heh
[19:45] <gregaf1> I think that means it's been peering since epoch 0, but that can't be right…probably it means no data is available and our initialization there sucks, let me check
[19:46] <pulsar> looks like i have got a lot of fuse mounts deadlocking other processes
[19:47] <pulsar> need to run, i'll read the chatlog later if you find some important bits
[19:49] <gregaf1> oh, the 0'0 is part of the next column, heh
[19:49] <gregaf1> so yeah, you need to bring those other nodes up
[20:04] * nhorman (~nhorman@nat-pool-rdu.redhat.com) Quit (Quit: Leaving)
[20:39] * fronlius (~fronlius@testing78.jimdo-server.com) Quit (Quit: fronlius)
[20:42] * nhorman (~nhorman@99-127-245-201.lightspeed.rlghnc.sbcglobal.net) has joined #ceph
[21:06] * fronlius (~fronlius@f054184172.adsl.alicedsl.de) has joined #ceph
[21:47] * nyeates (~nyeates@pool-173-59-237-128.bltmmd.fios.verizon.net) has joined #ceph
[21:53] * nyeates (~nyeates@pool-173-59-237-128.bltmmd.fios.verizon.net) Quit (Quit: Zzzzzz)
[22:11] * lofejndif (~lsqavnbok@207.Red-88-19-214.staticIP.rima-tde.net) has joined #ceph
[22:24] * nhorman (~nhorman@99-127-245-201.lightspeed.rlghnc.sbcglobal.net) Quit (Quit: Leaving)
[22:41] * dhansen (~dave@static-50-53-34-95.bvtn.or.frontiernet.net) has joined #ceph
[23:07] * andreask (~andreas@chello062178013131.5.11.vie.surfer.at) has joined #ceph
[23:10] <darkfader> what is "gceph"? :))
[23:10] <darkfader> gui-ceph?
[23:11] <gregaf1> yeah, but it's lame
[23:11] <darkfader> lol interesting
[23:11] <darkfader> i'll have a lot at it some time
[23:13] <dmick> darkfader: make it less lame :)
[23:13] <darkfader> dmick: hehe i can't code, sorry
[23:14] <dmick> aww.
[23:14] <darkfader> especially not on a "robust ultra-critical gui" level
[23:14] <darkfader> if you've ever seen the newer veritas cluster gui you know how failure looks like at that level
[23:15] <dmick> I'm happy to say I have not
[23:15] <darkfader> hehe
[23:16] <darkfader> meh it needs a config file to open ;)
[23:19] <darkfader> so i just totally need a 1-osd-mds-mon setup in my laptop now
[23:31] <darkfader> if i wanna use xfs on the osd, is it just "dev = /dev/vgblah/lvblah"?
[23:31] <darkfader> since in btrfs it was btrfs dev
[23:31] * darkfader has the nagging feeling he's looking at outdated docs
[23:41] * aliguori (~anthony@32.97.110.59) Quit (Remote host closed the connection)
[23:44] * fronlius (~fronlius@f054184172.adsl.alicedsl.de) Quit (Quit: fronlius)
[23:46] * fronlius (~fronlius@f054184172.adsl.alicedsl.de) has joined #ceph
[23:49] * andreask (~andreas@chello062178013131.5.11.vie.surfer.at) has left #ceph
[23:54] <gregaf1> darkfader: brfs is special since the ceph-osd handles formatting and stuff on its own
[23:55] <darkfader> gregaf1: can i waste 10 seconds of your time?
[23:55] <gregaf1> for other FSes you just specify the directory using, yes, I believe "dev"
[23:55] <darkfader> oh maybe that was the error
[23:55] * aa (~aa@r200-40-114-26.ae-static.anteldata.net.uy) Quit (Remote host closed the connection)
[23:55] <darkfader> [osd]
[23:55] <darkfader> osd data = /data/osd$id
[23:55] <darkfader> osd journal = /data/osdj$id
[23:55] <darkfader> i had this now
[23:55] <gregaf1> *checks*
[23:56] <darkfader> and it gave me something like "is a directory" for both of them
[23:56] <gregaf1> actually, no, it should be osd data and osd journal
[23:56] <darkfader> it'd be all xfs
[23:56] <darkfader> ok then in theory i got it right
[23:56] <darkfader> i'll pastebin it, 1 moment
[23:57] <gregaf1> yeah, you want to have done mkdir "/data/osd1"
[23:57] <gregaf1> I don't think you should have done anything for the journal, though
[23:59] <darkfader> http://paste.ie/128

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