--- Day changed

--- Log opened Tue May 03 23:59:02 2005
00:15 -!- tierra [~tierra@dsl093-225-126.slc1.dsl.speakeasy.net] has quit [Quit: bug, n: A son of a glitch.]
00:46 -!- rusty [~rusty@bh02i525f01.au.ibm.com] has quit [Read error: Connection reset by peer]
01:44 -!- Bluefox [~bluefox@pcp484971pcs.whtmrs01.md.comcast.net] has quit [Ping timeout: 480 seconds]
02:14 -!- Squink [~purple@S010600131077a67e.vc.shawcable.net] has joined #xen
02:30 < Squink> hey
03:15 -!- zsting [~sting@mvil2.bb.netvision.net.il] has joined #xen
03:33 -!- rusty [~rusty@bh02i525f01.au.ibm.com] has joined #xen
04:20 -!- rusty [~rusty@bh02i525f01.au.ibm.com] has quit [Quit: Client exiting]
04:22 -!- heb_away is now known as heb
04:28 -!- sleon [~sleon@129.69.221.149] has joined #xen
04:28 < sleon> hi
04:28 < sleon> how can i define a virtual network between all doamins
04:28 < sleon> domains
04:54 < mael> just as you would do for normal linux machines
04:54 < mael> define network cards, a common adressing scheme
05:04 -!- athomas [~athomas@ppp-0-127.lond-a-4.access.uk.tiscali.com] has joined #xen
05:06 < sleon> mael, hmmmm
05:20 -!- athomas [~athomas@ppp-0-127.lond-a-4.access.uk.tiscali.com] has quit [Ping timeout: 480 seconds]
05:21 -!- athomas [~athomas@ppp-0-151.lond-b-3.access.uk.tiscali.com] has joined #xen
05:37 -!- zsting [~sting@mvil2.bb.netvision.net.il] has quit [Quit: ]
05:37 < mael> sleon:  no?
05:38 -!- Tv [~Tv@hq.inoi.fi] has quit [Ping timeout: 480 seconds]
05:43 -!- Sting [~sting@mvil2.bb.netvision.net.il] has joined #xen
06:08 -!- Bluefox [~bluefox@pcp0012067827pcs.whtmrs01.md.comcast.net] has joined #xen
06:11 -!- Tv [~Tv@ssg.masterplanet.fi] has joined #xen
06:16 -!- bunoc [~bunoc@YahooBB219206220072.bbtec.net] has joined #xen
06:28 < bunoc> anybody could tell me why we need "make mkpatches"? 
06:28 < bunoc> from what i seen, make mkpatches produces exactly *sparse ?
06:45 < knewt> bunoc: you can [attempt to] apply the patches over the top of other patches, unlike *sparse
06:49 < bunoc> knewt, "other patches"? what do you mean?
06:50 < knewt> let's say you have a kernel tree already patched with some other patches, and you want to apply xen on top of it. you can't do so using *sparse
06:50 < bunoc> knewt, from what i seen, *sparse is also kind of patch. what is special with it?
06:51 < knewt> *sparse isn't a patch. it has /replacement/ files where a file has changes in it
06:51 < bunoc> i looked at Makefiles, and it seems that they just overwrite the original files with files from sparse
06:51 < bunoc> ah i see
06:52 < bunoc> but why they dont provide patch, instead of *sparse ?
06:52 < knewt> sparse is easier for them to develop with
06:52 < bunoc> i see they are same
06:53 < knewt> for myself i generally apply sparse and then put some other patches on top, but for distro people it's a lot easier to include xen in their pipeline if it's available as a normal patch
06:54 < bunoc> ok, suppose that *sparse dont have conflict with the original files, so what is difference with using it with "other patches"? we can still apply other patches on top of xen, rite?
06:55 < bunoc> i dont see the clear benefit here
06:56 < knewt> /if/ nothing in *sparse was changed by any previous patches, then it will work to apply *sparse on top
06:57 < knewt> however, lets say that a patch changed 5 files, and 1 of them is touched by *sparse. not the change to that 1 file from the patch has been lost. uh oh.
06:58 < knewt> s/not the/now the/
06:58 < bunoc> ok, so one benefit is we will know if there is conflict of not when apply "sparse" as patch
06:58 < bunoc> s/of not/or not/
06:59 < knewt> remember, applying sparse as a patch instead in the last example might work fine without producing any conflicts
07:03 -!- DEac- [~deac@xdsl-84-44-145-16.netcologne.de] has quit [Quit: Verlassend]
07:04 -!- DEac- [~deac@xdsl-84-44-145-16.netcologne.de] has joined #xen
07:18 -!- sleon [~sleon@129.69.221.149] has quit [Quit: Verlassend]
09:01 -!- Tv [~Tv@ssg.masterplanet.fi] has quit [Ping timeout: 480 seconds]
09:05 -!- katzj [~katzj@c-66-30-206-55.hsd1.ma.comcast.net] has quit [Ping timeout: 480 seconds]
09:07 -!- Sting [~sting@mvil2.bb.netvision.net.il] has quit [Remote host closed the connection]
09:09 -!- DEac- [~deac@xdsl-84-44-145-16.netcologne.de] has quit [Ping timeout: 480 seconds]
09:22 -!- DEac- [~deac@xdsl-213-168-105-198.netcologne.de] has joined #xen
09:30 -!- Tv [~Tv@hq.inoi.fi] has joined #xen
09:32 -!- bunoc [~bunoc@YahooBB219206220072.bbtec.net] has quit [Quit: Leaving]
09:41 -!- hollis [~hollis@user-0vvde2g.cable.mindspring.com] has joined #xen
10:06 -!- katzj [~katzj@wlanconf-nat-pool-bos.redhat.com] has joined #xen
10:13 -!- rharper [~rharper@pixpat.austin.ibm.com] has joined #xen
10:15 -!- Squink [~purple@S010600131077a67e.vc.shawcable.net] has quit [Ping timeout: 480 seconds]
10:19 -!- hollis [~hollis@user-0vvde2g.cable.mindspring.com] has quit [Quit: leaving]
10:36 -!- cfreak [cfreak@dsl-084-056-125-058.arcor-ip.net] has joined #xen
11:00 -!- hollis [~hollis@pixpat.austin.ibm.com] has joined #xen
11:39 -!- plars [~plars@pixpat.austin.ibm.com] has joined #xen
11:49 -!- cfreak [cfreak@dsl-084-056-125-058.arcor-ip.net] has quit [Quit: .]
11:51 -!- aliguori [~anthony@pixpat.austin.ibm.com] has joined #xen
13:06 -!- stekloff [~stekloff@bi01p1.co.us.ibm.com] has joined #xen
13:08 -!- niv [~nivedita@bi01p1.co.us.ibm.com] has joined #xen
13:17 -!- tierra [~tierra@dsl093-225-126.slc1.dsl.speakeasy.net] has joined #xen
13:36 -!- athomas [~athomas@ppp-0-151.lond-b-3.access.uk.tiscali.com] has quit [Quit: Leaving]
13:46 -!- woody [~woody@bi01p1.co.us.ibm.com] has joined #xen
13:48 -!- woody [~woody@bi01p1.co.us.ibm.com] has quit [Quit: ]
14:18 -!- tierra [~tierra@dsl093-225-126.slc1.dsl.speakeasy.net] has quit [Ping timeout: 480 seconds]
14:20 -!- tierra [~tierra@dsl093-225-126.slc1.dsl.speakeasy.net] has joined #xen
14:23  * caker hits the "domain stuck in s state" problem again
14:23  * mikegrb hits caker
14:38 -!- matta-lt [~matta@69.93.28.254] has joined #xen
14:39 -!- woody [~woody@bi01p1.co.us.ibm.com] has joined #xen
15:01 -!- niv [~nivedita@bi01p1.co.us.ibm.com] has quit [Quit: Quitting]
15:37 -!- niv [~nivedita@bi01p1.co.us.ibm.com] has joined #xen
15:53 -!- Tv [~Tv@hq.inoi.fi] has quit [Quit: Client exiting]
15:58 -!- cartel [~cartel@shinobi.thoughtcrime.org.nz] has quit [Ping timeout: 480 seconds]
16:06 -!- cartel [~cartel@shinobi.thoughtcrime.org.nz] has joined #xen
16:06 -!- TheQ [~TheQ@dial4a-65.btc-bci.com] has joined #xen
17:01 -!- Nigelenki [~bluefox@69.251.146.225] has joined #xen
17:05 -!- Bluefox [~bluefox@pcp0012067827pcs.whtmrs01.md.comcast.net] has quit [Ping timeout: 480 seconds]
17:51 -!- katzj [~katzj@wlanconf-nat-pool-bos.redhat.com] has quit [Read error: Connection reset by peer]
17:51 -!- matta-lt [~matta@69.93.28.254] has quit [Quit: I used to have a drinking problem.  Now I love the stuff.]
18:22 -!- hbaum__ [~hbaum@bi01p1.co.us.ibm.com] has quit [Quit: Client exiting]
18:27 -!- Icy [~bluefox@pcp0012067827pcs.whtmrs01.md.comcast.net] has joined #xen
18:27 -!- Nigelenki [~bluefox@69.251.146.225] has quit [Read error: Connection reset by peer]
18:27 -!- hbaum [~hbaum@bi01p1.co.us.ibm.com] has joined #xen
18:45 -!- aliguori [~anthony@pixpat.austin.ibm.com] has quit [Quit: Leaving]
18:46 -!- Nigelenki [~bluefox@pcp0012067827pcs.whtmrs01.md.comcast.net] has joined #xen
18:47 -!- Icy [~bluefox@pcp0012067827pcs.whtmrs01.md.comcast.net] has quit [Read error: Operation timed out]
18:56 -!- katzj [~katzj@c-66-30-206-55.hsd1.ma.comcast.net] has joined #xen
19:16 -!- stekloff [~stekloff@bi01p1.co.us.ibm.com] has quit [Quit: Leaving]
19:22 < cartel> heh
19:32 -!- hollis [~hollis@pixpat.austin.ibm.com] has quit [Quit: leaving]
19:40 -!- MarkWilliamson [~MarkW@maw48.kings.cam.ac.uk] has joined #xen
19:42 < cartel> hey Mark
19:45 < knewt> MarkWilliamson: 'lo there. header-mode isn't implemented yet, but i've got my CoW driver working :)
19:46 < cartel> knewt: copy on write?
19:46 < knewt> yep. it's a 1->1 implementation, but that's still very useful
19:46 < eigood> I've been working on a COW thing for java/commons-vfs
19:46 < eigood> including multiple internal COW links, and multiple COW links per dir
19:46 < cartel> isnt that functionality in lvm already?
19:47 < eigood> at a file level, including svn hooks, to maintain history
19:47 < knewt> the snapshot stuff is crap
19:47 < cartel> lol
19:47 < cartel> so your cow driver is for xen only?
19:47 < MarkWilliamson> knewt: nice one!
19:47 < knewt> cartel: nope. it's a pure device-mapper driver
19:47 < cartel> knewt: nice!!!
19:47 < MarkWilliamson> cartel: hi
19:47 < cartel> knewt: with userland tools?
19:48 < knewt> cartel: i could email you the patch of what's done so far, but right now there's no documentation at all, no comments in the code, and the code needs to be neatened up layout-wise
19:49 < cartel> knewt: cool, i dont need it yet, but it will be nice to have, comment it and send to the devmapper guys
19:49 < knewt> first thing i'm going to do is post to the xen list and ask for some guinea-pigs^Wtesters. after i'm feeling reasonably confident i'll post to the devmapper address
19:50 < MarkWilliamson> knewt: for testing this sort of thing it'd be nice to have a kind of "virtual machine" technology
19:50 < MarkWilliamson> oh, hang on...
19:50 < cartel> lmao
19:50 < knewt> MarkWilliamson: heh. the boot time of a domU came in very handy during development :)
19:51 < MarkWilliamson> indeed!
19:51 < cartel> MarkWilliamson: have you heard of these nsp guys that simon keeps going on about?
19:51 < knewt> i've been developing on my laptop, rebuilding the kernel, scp'ing it up to the server, and then booting a domU and testing it out. and then back to the start we go.
19:51 < cartel> knewt: i managed to get our kernel guy to start using xen for our netfilter stuff
19:51 < MarkWilliamson> knewt:  you could cut down startup times during development even more if you used suspend resume.  but of course then you'd want a CoW block device :-p
19:52 < knewt> MarkWilliamson: i've been building it into the kernel, rather than as a module
19:52 < MarkWilliamson> cartel: nope.   simon who?
19:52 < cartel> crosby
19:53 < knewt> and when i managed to Oops it a reboot is frequently needed anyway
19:53 < MarkWilliamson> cartel: ah.  what does NSP stand for?
19:53 < cartel> network service providers
19:53 < MarkWilliamson> knewt: indeed.  i've never developed any code as a module.
19:54 < MarkWilliamson> cartel: still nope - what's simon saying about them?  and what do they do?
19:54 < knewt> my best crash imo was when i made a small mistake in the parameters i gave to an existing bit of the kernel code, and it then caused an oops in a seperate task
19:54 < MarkWilliamson> knewt: that's always entertaining :-)
19:54 < cartel> MarkWilliamson: im just testing you since im tom@nsp :) Simon seems to be foaming at the mouth to get us promoted, since we've adopted xen for our product range
19:54 < knewt> the crash happening because a count parameter that was passed in was assumed to always be at least 1, and if it was 0 it led to code traversing off the end of a linked list
19:55 < MarkWilliamson> my best crash was when Xen had an error unpinning an L3 page table entry.  on an arch with two level page tables, that's quite scary :-)
19:55 < cartel> MarkWilliamson: to our knowlege i have the only replicated root raid xen+heartbeat set up replicated mail server in the world
19:55 < knewt> the background cowifying is working quite nicely now :)
19:55 < MarkWilliamson> cartel: ah, that's quite funky!
19:55 < MarkWilliamson> knewt: way cool
19:56 < knewt> it runs as a nice 19'ed task
19:56 < cartel> MarkWilliamson: its what happens when you work 40 hours straight trying to come up with a replication scenario on a weekend after the client's mta toasted itself 
19:56 < MarkWilliamson> cartel: i suppose that would have a motivating effect!
19:56 < cartel> MarkWilliamson: i have to say i threw 70,000 smtp sessions at the thing and it still trundled along
19:56 < knewt> and whenever external CoW activity happens on the device (reads and already mapped areas for writes don't count), it slows itself down even more
19:57 < MarkWilliamson> knewt: makes sense
19:57 < cartel> ok guys, bbiab, off to grab lunch
19:57 < MarkWilliamson> cartel: that's quite impressive!
19:57 < MarkWilliamson> (smtp scaling, not the lunch ;-))
19:57 < knewt> MarkWilliamson: i did a very basic speed test btw. 1 gig of /dev/zero being written out at a block size of 1 meg
19:57 < knewt> linear mapping: 28.33s, 0.08 stdev
19:58 < knewt> cow memory-only-bitmap: 28.71s, 0.06 stdev
19:58 < knewt> cow interleaved-bitmap: 33.38s, 0.04 stdev
19:58 < MarkWilliamson> impressive
19:58 < knewt> cow seperate-bitmap: 34.45s, 0.07 stdev
19:58 < MarkWilliamson> relatively painless
19:59 < knewt> oh, and you do indeed read correctly. i implemented the interleaved bitmap/cow that you mentioned the other day :)
19:59 < MarkWilliamson> nice one!
19:59 < knewt> it was quite painless to implement actually. actually took longer to code the configuration code 
19:59 < knewt> for it
19:59 < MarkWilliamson> you require a cow device the same size as the origin, though, right?
20:00 < knewt> yeah
20:00 < MarkWilliamson> are you considering dropping that restriction at some point?
20:00 < knewt> covers a lot of usages though
20:00 < MarkWilliamson> sure
20:01 < knewt> MarkWilliamson: would have to write a completely seperate target for a sparse version. been considering it, but it's a matter of not using up overly large amounts of memory, whilst keeping it reasonably fast
20:01 < knewt> i've been running lots of ideas through my head, but haven't settled on anything for sure yet
20:01 < MarkWilliamson> yup, it's a bit of a fiddly problem.
20:01 < MarkWilliamson> it's nice for people who want to be miserly with disk space ;-)
20:01 < knewt> for now, if you really want a sparse cow, you can use a loopback, but that slows it down just a tad
20:02 < eigood> COW block drivers can't be hard; a COW filesystem layer is more complex
20:02 < knewt> i used loopback devices during development from within a domU, but the speed tests i did were starting that domU over a cow device :)
20:02 < knewt> eigood: it's hard to do both fast and memory efficiently
20:03 < knewt> if you don't want a 1-1 implementation, but a sparse implementation
20:03 < knewt> what i've been working on is a 1-1 implementation, but once i'm done i might have a go at a sparse version
20:06 -!- niv [~nivedita@bi01p1.co.us.ibm.com] has quit [Quit: Quitting]
20:52 -!- rusty [~rusty@bh02i525f01.au.ibm.com] has joined #xen
21:21 -!- lilo [~lilo@lilo.usercloak.oftc.net] has quit [Read error: Connection reset by peer]
21:43 -!- lilo [~lilo@lilo.usercloak.oftc.net] has joined #xen
21:43 -!- DEac- [~deac@xdsl-213-168-105-198.netcologne.de] has quit [Ping timeout: 480 seconds]
21:55 -!- DEac- [~deac@xdsl-81-173-161-32.netcologne.de] has joined #xen
22:00 -!- Squink [~purple@S010600131077a67e.vc.shawcable.net] has joined #xen
22:05 -!- lilo [~lilo@lilo.usercloak.oftc.net] has quit [Quit: brb]
22:57 -!- Nigelenki [~bluefox@pcp0012067827pcs.whtmrs01.md.comcast.net] has quit [Read error: Connection reset by peer]
22:59 -!- Nigelenki [~bluefox@pcp0012067827pcs.whtmrs01.md.comcast.net] has joined #xen
23:05 -!- superdave591 [~superdave@danders5.cs.uiuc.edu] has joined #xen
23:27 -!- Icy [~bluefox@pcp0012067827pcs.whtmrs01.md.comcast.net] has joined #xen
23:29 -!- Nigelenki [~bluefox@pcp0012067827pcs.whtmrs01.md.comcast.net] has quit [Read error: Operation timed out]
23:34 -!- MarkWilliamson [~MarkW@maw48.kings.cam.ac.uk] has left #xen [Kopete 0.10 : http://kopete.kde.org]
23:38 -!- Nigelenki [~bluefox@pcp0012067827pcs.whtmrs01.md.comcast.net] has joined #xen
23:38 -!- Icy [~bluefox@pcp0012067827pcs.whtmrs01.md.comcast.net] has quit [Read error: Connection reset by peer]
--- Log closed Wed May 04 23:59:01 2005