1215648128 Q * ntrs__ Ping timeout: 480 seconds
1215648129 J * ard ~ard@shell2.kwaak.net
1215649408 Q * dowdle Remote host closed the connection
1215649567 J * doener_ ~doener@i577BB8BD.versanet.de
1215649667 Q * doener Ping timeout: 480 seconds
1215655833 J * darkpsi ~no@72-48-199-234.dyn.grandenetworks.net
1215655844 M * darkpsi hey everyone
1215655857 M * darkpsi could I get some help stabilizing my Vserver implementation?
1215655876 M * darkpsi i'm well familiar with running it in general; i've been running it with no problem on my home machine, running Gentoo
1215655893 M * darkpsi I just finished setting up a linux server from scratch
1215655898 M * darkpsi (built the whole thing from a makefile!)
1215655902 M * darkpsi however..
1215655912 M * darkpsi vserver is acting highly unstable.
1215655947 M * darkpsi it WILL start vservers, but the sysklogd init script hangs for a quite a while (i know, it proly shouldn't be starting in the vserver)
1215655956 M * darkpsi so, i turned it off
1215655965 M * darkpsi now, the vserver starts, and then exits immediately
1215655984 M * darkpsi and afterwards, any attempt to find the vservers's (the one that started and scrashed)
1215655985 M * infowolfe that's because there's nothing actually running inside the vserver
1215655999 M * infowolfe make some other service start on boot
1215656016 M * darkpsi fails, however there is some state being retained as vserver complains about "can't get xid"
1215656019 M * infowolfe even something like 'screen top' should keep the context open
1215656035 M * darkpsi rebooting gives me another try. vkill -c <ctx> didn't help... (not found)
1215656036 M * infowolfe and if you vserver $vs enter  you should get in fine
1215656039 M * darkpsi thanks infowolfe.
1215656053 M * darkpsi yes,
1215656068 M * infowolfe how are you expecting a context to stay open if there's nothing running inside it?
1215656076 M * darkpsi while sysklogd is hanging, i can CTRL-Z bg vserver base enter
1215656089 M * darkpsi so it starts, but when the rc scripts finish it dies
1215656098 M * infowolfe use syslog-ng instead?
1215656100 M * darkpsi i read something about appendinf "true" to the end of rc
1215656102 M * darkpsi which i tried.
1215656107 M * darkpsi also tried exit 0 and exit 1
1215656108 M * darkpsi no luck
1215656114 M * darkpsi *nod*
1215656114 M * infowolfe use syslog-ng instead?
1215656121 M * darkpsi sure, will do.
1215656136 M * darkpsi how can i get vserver to act sane again when this happens?
1215656151 M * darkpsi is there somewhere in /proc I can find the truth?
1215656165 M * infowolfe it's not vserver that's not acting sane
1215656167 M * infowolfe it's pebkac
1215656170 M * darkpsi after base (my vserver) crashes, it won't start it anymore
1215656172 M * infowolfe and/or crap services
1215656205 M * infowolfe but if you vserver base enter, then start -another- service, then try to vserver base stop, you can then vserver base start again, right?
1215656207 M * darkpsi pebkac?
1215656214 M * infowolfe problem exists between keyboard and chair
1215656219 M * infowolfe it's a polite way of saying 'user error'
1215656224 M * darkpsi heh. sounded familiar :)_
1215656235 M * darkpsi thanks for clearing that up
1215656237 M * darkpsi ;P
1215656249 M * darkpsi alright.
1215656250 M * infowolfe so, how do you fix your problem? 1) stop using a logger that is dumb
1215656251 M * darkpsi to clarify.
1215656261 M * infowolfe 2) make sure you start more services than the logger that doesn't work
1215656277 M * darkpsi vserver base start  -- used to show the rc scripts, but hung on a few of them (admittedly, shouldn't be running in a vserver)
1215656306 M * infowolfe 3) if 1 and 2 can't be fulfilled, vserver $vs enter; start service ; vserver $vs stop ; vserver $vs start (that is, if you believe you need to needlessly stop and start a vs that is running properly, despite having no running processes)
1215656313 M * darkpsi when I removed the services that hung (prolly all of them, i'll try that, it started, then crashed, and then wouldn't let me vserver base stop , vserver base start, OR vkill -c ctx
1215656326 M * infowolfe obviously
1215656330 M * infowolfe because there's nothing to kill, right?
1215656336 M * darkpsi right.
1215656340 M * infowolfe then _start_ something
1215656345 M * darkpsi but after the first crash, vserver start won't try again
1215656354 M * darkpsi it says "can't get xid ... '' "
1215656357 M * infowolfe then you'll be able to stop/start/do whatever you think you need to do even though it's really ineffectual
1215656357 M * darkpsi or something similar.
1215656363 M * darkpsi lemme give it a svc
1215656363 M * infowolfe again
1215656365 M * infowolfe obviously
1215656371 M * darkpsi 1 sec.
1215656374 M * darkpsi i appreciate your help.
1215656378 M * infowolfe the context *HAS* been created
1215656378 M * darkpsi i'm up against a wall here :)
1215656385 M * infowolfe just doesn't have anything running inside it
1215656388 M * darkpsi aha
1215656404 M * darkpsi how can i get a list of created contexts, low-level? anywher ein /proc or /sys?
1215656458 M * infowolfe beta01:/proc/virtual$ cat /proc/virtual/100/status
1215656458 M * infowolfe UseCnt: 58
1215656458 M * infowolfe Tasks:  20
1215656476 M * darkpsi i THOUGHT that was the place
1215656493 M * darkpsi all I have is info & status, no numbered directories
1215656505 M * darkpsi and the contents of those are virtually meaningless, no pun intended
1215656521 M * infowolfe perhaps only to someone that doesn't know what they mean
1215656535 M * darkpsi indeed.
1215656551 M * infowolfe there's actually a crapload of information in those files ;)
1215656582 M * darkpsi well, I have three lines each.  info has VCIVersion, VCISyscall, VCIKernel.
1215656594 M * darkpsi status has #CTotal, #Cactive, #NSProxy
1215656604 M * infowolfe do this:
1215656604 M * darkpsi each has a few numbers
1215656606 M * darkpsi ok
1215656607 M * infowolfe vps aux | grep -v MAIN
1215656641 M * darkpsi there's the monitoring context
1215656647 M * darkpsi tisk tisk
1215656661 M * darkpsi i read about it, but didn't see it
1215656669 M * darkpsi forgot about vps.. 
1215656671 M * darkpsi thanks
1215656683 M * infowolfe but you have nothing running under base, right?
1215656695 M * darkpsi not yet, i haven't started it
1215656706 M * darkpsi btw, what do I want apropos vshelper.
1215656711 M * darkpsi i initially chose to "enable" it
1215656724 M * darkpsi ie, kernel.vshelper = /usr/local/src/util-vserver/bld/lib/util-vserver/vshelper
1215656734 M * darkpsi oops
1215656735 M * darkpsi i mean
1215656737 M * infowolfe no idea
1215656741 M * darkpsi  echo "/usr/local/src/util-vserver/bld/lib/util-vserver/vshelper" >/proc/sys/kernel/vshelper
1215656741 M * infowolfe your setup is your setup
1215656751 M * infowolfe and they're the same thing btw
1215656765 M * darkpsi yeah, i know
1215656776 M * darkpsi but what do I lose by not having it, or gain by having?
1215656787 M * infowolfe so if /usr/local/src/util-vserver is where your util-vserver is installed, that's the line you use
1215656794 M * infowolfe no idea, don't really care
1215656797 M * darkpsi k
1215656821 M * darkpsi alright.
1215656834 M * darkpsi initial try of _base_ WITHOUT adding service back, says this:
1215656839 M * darkpsi vshelper.init: can not determine xid of vserver '_base_'; returned value was ''
1215656842 M * darkpsi vps says...
1215656881 M * darkpsi only contexts 0 and 1.  main(#0) has a bash, ALL_proc(#1) has vps and ps
1215656894 M * infowolfe again, obviously
1215656899 M * darkpsi yup.
1215656901 M * infowolfe you're not running anything in the context, so nothing would show up
1215656902 M * darkpsi putting in a service
1215656926 M * darkpsi so the xid complaint is simply "process terminated prematurely", basically
1215656944 M * infowolfe so vserver base enter
1215656948 M * infowolfe and type "screen top"
1215656954 M * infowolfe then you've got something *in* the context
1215656961 M * infowolfe so if you tried shutting it down, it should work
1215657074 M * darkpsi okay.
1215657083 M * darkpsi added sysklogd back, (for lack of a better quick option)
1215657096 M * darkpsi starting sysem log daemon..ok
1215657109 M * darkpsi starting kerenl log daemon... ... ... (hang)
1215657118 M * darkpsi if I ctrl z or ctrl c
1215657131 M * darkpsi i can then do a vserver _base_ enter
1215657134 M * darkpsi and i'm in
1215657138 M * darkpsi (same as yesterday.
1215657146 M * darkpsi but when this crashes, we'll ge tto see what vps says
1215657167 M * darkpsi oh
1215657171 M * darkpsi ohhhh
1215657226 M * darkpsi btw, i think the missing key I needed to "hel myself" was vps
1215657232 M * darkpsi i should be able to work it out form there
1215657273 M * darkpsi rc & sysklogd (the rc script) and klogd (the dameon) are showing in vps | grep _base)
1215657312 M * infowolfe um
1215657321 M * darkpsi well that exmplains quite a lot actually, i was under the impresison that INIT is spawned, and the "vserver is up" as long as that init runs
1215657324 M * infowolfe you're not so good at reading documentation, eh?
1215657326 M * darkpsi but there's no init here at all
1215657333 M * darkpsi i'm up against a wall.
1215657337 M * infowolfe let me say this once more
1215657345 M * infowolfe do *NOT* use sysklogd
1215657354 M * infowolfe there can be only ONE kernel logger per box
1215657355 M * darkpsi *nod* i get it that :)
1215657365 M * infowolfe which is why it's not working
1215657372 M * infowolfe which is also very well documented
1215657381 M * infowolfe please use syslog-ng instead, because it's not braindead ;)
1215657386 M * darkpsi i was really curious how I can get info out of vserver when it starts telling me that non-running vservers are already running until i try to stop them, at which time it tells me they're not running :)
1215657391 M * darkpsi vps is the key
1215657478 M * darkpsi sure enough
1215657478 M * darkpsi okay.
1215657485 M * darkpsi sysklog finally borked
1215657494 M * darkpsi and vps show's everything gone
1215657512 M * infowolfe did you have any services other than sysklogd configured to boot with the box?
1215657513 M * darkpsi ...but!
1215657521 M * darkpsi i can still enter now :)
1215657525 M * darkpsi weird weird weird
1215657529 M * infowolfe no
1215657531 M * infowolfe working as expected
1215657537 M * darkpsi yes, syslog and klog.
1215657542 M * infowolfe ...
1215657546 M * darkpsi i'm about to put something more meaningful there.
1215657556 M * darkpsi hehe
1215657567 M * darkpsi it's weird 'cause yesterday vserver simply denied me
1215657588 M * darkpsi today, infowolfe magic remote touch is having it's effect
1215657612 M * infowolfe i have to go, read the docs ;)
1215657622 M * darkpsi thanks dude.  
1215657936 M * darkpsi btw, for anyone listenning /proc/virtual DOES show the started context, although vps shows nothing unless entered.
1215657949 M * darkpsi reiterating infowolfe... pebkac
1215657956 M * darkpsi peace, all.
1215657960 P * darkpsi 
1215659114 Q * FloodServ charon.oftc.net services.oftc.net
1215659269 J * FloodServ services@services.oftc.net
1215659449 J * darkpsi ~no@72-48-199-234.dyn.grandenetworks.net
1215659451 M * darkpsi alright.
1215659458 M * darkpsi seems to be stable now
1215659468 M * darkpsi took out klogd, ensured syslog stays up. no probs.
1215659474 M * darkpsi one little bit of weirdness left tho
1215659484 M * darkpsi on $ vserver base stop
1215659498 M * darkpsi after everything is stopped, i get this message: lib/util-vserver/vserver.stop: line 85:  4578 Killed                  "${NICE_CMD[@]}" ${USE_VNAMESPACE:+$_VNAMESPACE --enter "$S_CONTEXT" -- } $_VCONTEXT $SILENT_OPT --migrate --chroot --xid "$S_CONTEXT" -- "${INITCMD_STOP[@]}"
1215659512 M * darkpsi didn't happen with the distro's version of vserver.
1215659516 M * darkpsi is that an error?
1215659620 M * darkpsi that's essentially line 85 verbatim, minus the || fail=1 part
1215659633 M * darkpsi sorry, "fail=1
1215659738 M * darkpsi can anybody shed any light on the difference beetween the various "init styles"
1215659750 M * darkpsi such as "gentoo init" and "Fakeinit" and so on?
1215660144 M * darkpsi anybody?
1215663251 J * blizz ~stephan@e181079180.adsl.alicedsl.de
1215663351 M * darkpsi blizz, you know anything about the "init styles"
1215663358 M * darkpsi gentoo init, fakeinit, etc?
1215663441 M * darkpsi btw all, the error message i was getting on $ vserver base stop, was because the rc?.d scripts were killing processes.  not sure precisely which one, but after cleaning it all up  to get rid of failures, the error is gone
1215663470 M * darkpsi i suspect halt or reboot or sysctl
1215663682 Q * Hollow Read error: Connection reset by peer
1215663687 J * Hollow ~hollow@proteus.croup.de
1215663751 P * darkpsi 
1215663777 Q * Hollow Remote host closed the connection
1215663845 Q * padde Remote host closed the connection
1215663886 Q * Loki|muh Remote host closed the connection
1215663958 Q * bzed Remote host closed the connection
1215664002 Q * DLange Remote host closed the connection
1215664168 J * Hollow ~hollow@proteus.croup.de
1215664207 J * bzed ~bzed@devel.recluse.de
1215664397 J * padde ~padde@patrick-nagel.net
1215664802 Q * Hollow Remote host closed the connection
1215664867 J * Hollow ~hollow@proteus.croup.de
1215664871 Q * bzed Remote host closed the connection
1215665631 Q * blizz Ping timeout: 480 seconds
1215666992 J * cryptronic ~oli@p54A3B20C.dip0.t-ipconnect.de
1215667770 Q * nkukard Quit: Leaving
1215667871 J * ntrs ~ntrs@77.29.71.74
1215668380 Q * cryptronic Quit: Leaving.
1215668649 J * nkukard ~nkukard@196.212.73.74
1215670420 J * DLange ~DLange@dlange.user.oftc.net
1215671015 J * DavidS ~david@p57A484B9.dip0.t-ipconnect.de
1215671972 J * Aiken_ ~james@ppp118-208-121-181.lns4.bne4.internode.on.net
1215672288 Q * Aiken Ping timeout: 480 seconds
1215672959 Q * Aiken_ Quit: Leaving
1215672976 J * Aiken ~james@ppp118-208-121-181.lns4.bne4.internode.on.net
1215674835 Q * DavidS Quit: Leaving.
1215674972 J * loddafnir ~mike@193.170.138.233
1215675123 J * z0d ~z0d@fw.wonderline.hu
1215675209 J * dna ~dna@132-202-dsl.kielnet.net
1215675266 M * z0d hello
1215675327 J * Aiken_ ~james@ppp118-208-121-181.lns4.bne4.internode.on.net
1215675643 Q * Aiken Ping timeout: 480 seconds
1215675923 Q * ntrs Ping timeout: 480 seconds
1215676673 Q * Hollow Read error: Connection reset by peer
1215676680 J * Hollow ~hollow@proteus.croup.de
1215678035 J * derjohn_mob ~aj@92.117.238.182
1215678127 J * bzed ~bzed@devel.recluse.de
1215678667 Q * balbir Ping timeout: 480 seconds
1215679061 J * doutrele ~doutrele@157.159.21.106
1215679070 M * doutrele hi there
1215679134 M * doutrele does someone know if there s a support on building f9 guest with the yum method?
1215679317 Q * derjohn_mob Ping timeout: 480 seconds
1215679343 J * balbir ~balbir@122.167.199.217
1215679685 J * Slydder ~chuck@194.59.17.53
1215681536 Q * doutrele Quit: Quitte
1215681638 J * friendly ~friendly@ppp59-167-145-230.lns4.mel6.internode.on.net
1215682557 J * derjohn_mob ~aj@92.117.2.86
1215684037 J * meandtheshell1 ~sa@88-117-23-155.adsl.highway.telekom.at
1215684342 M * meandtheshell1 hi folks, is it possible to stretch one VPS over more than one node e.g. I have a BladeCenter, two blades, two sockets each i.e. four sockets and possibly 16 CPU cores in case I am using quad core CPUs. Now I want to span a VPS over those two blades so ONE VPS can use TWO nodes/blades ... is this possible? Storage would be mounted from a SAN backend into the VPS.
1215685792 M * harry not possible afaik
1215685804 M * harry you'd want numa stuff :)
1215686032 N * DoberMann[ZZZzzz] DoberMann
1215686246 J * kir ~kir@swsoft-msk-nat.sw.ru
1215687291 Q * derjohn_mob Ping timeout: 480 seconds
1215687418 M * pmjdebruijn meandtheshell1: please note that usually blade are plain computers in a shared enclosure
1215687433 M * pmjdebruijn meandtheshell1: you basically want vserver based mosix
1215687453 M * pmjdebruijn meandtheshell1: it's probably not possible
1215687753 M * waldi pmjdebruijn: mosix is dead
1215687902 M * pmjdebruijn oh probably
1215687951 M * pmjdebruijn but that would the idea
1215687959 J * sebastiandeutsch ~sebastian@i538773C5.versanet.de
1215687976 M * pmjdebruijn anyway, two kernel patches which heavily alter the base kernel... that would never work
1215687981 M * pmjdebruijn meandtheshell1: why would you want that
1215688078 P * sebastiandeutsch 
1215689121 J * ntrs ~ntrs@77.29.71.74
1215689262 M * meandtheshell1 pmjdebruijn: "I am a nosy person, therefore I ask. --meandtheshell, 1983-" ;)
1215689345 M * pmjdebruijn meandtheshell1: you can more or less simulate what you want with heartbeat
1215689434 M * meandtheshell1 well, yes, there is Linux HA, Ultramonkey, ZEO (for Plone), etc. but it would just be nice to have this opportunity ... my guess, only a matter of time anyways ...
1215689541 J * ntrs_ ~ntrs@77.29.77.4
1215689910 J * sebastiandeutsch_ ~sebastian@i53874491.versanet.de
1215689922 Q * ntrs Ping timeout: 480 seconds
1215690123 N * Bertl_zZ Bertl
1215690130 M * Bertl morning folks!
1215690402 M * z0d hi
1215691222 Q * ntrs_ Read error: Connection reset by peer
1215691689 J * docelic ~docelic@78.134.205.212
1215692008 J * docelic_ ~docelic@78.134.194.163
1215692441 Q * docelic Ping timeout: 480 seconds
1215692466 Q * friendly Quit: Leaving.
1215693659 J * yarihm ~yarihm@whitehead2.nine.ch
1215693776 M * pmjdebruijn meandtheshell1: actually probably not, like waldi said... mosix is dead
1215693925 M * pmjdebruijn meandtheshell1: it probably won't be possible... anytime soon
1215693940 M * waldi meandtheshell1: do you have the infiniband or myrienet installation do make this usable?
1215693942 M * pmjdebruijn meandtheshell1: like I said, blades aren't special
1215693958 M * pmjdebruijn waldi: mosix used to work via ethernet as well, didn't it?
1215693985 M * waldi pmjdebruijn: only if the process only used cpu no i
1215693988 M * waldi s/i$/io/
1215694029 M * pmjdebruijn ok
1215694032 M * waldi all io things (to be exact all syscalls) was executed by the home-node
1215694039 M * pmjdebruijn ok
1215694044 M * pmjdebruijn that's a major downside
1215694056 M * waldi and ethernet have a large latency
1215694073 M * daniel_hozac and disks don't? :-)
1215694113 M * waldi i said io, not disk. there are many types of io
1215694138 Q * Slydder Quit: Leaving.
1215694213 Q * Aiken_ Quit: Leaving
1215694390 J * Aiken ~james@ppp118-208-121-181.lns4.bne4.internode.on.net
1215694427 Q * meandtheshell1 Ping timeout: 480 seconds
1215695142 Q * tzanger Ping timeout: 480 seconds
1215695780 P * sebastiandeutsch_ 
1215696534 M * daniel_hozac Bertl: http://people.linux-vserver.org/~dhozac/p/k/delta-pidspace-feat01.diff
1215696733 M * daniel_hozac does not handle entering yet, but it does let you run a guest without an init process.
1215696744 M * Bertl nice, okay, that eliminates all the existing pid virtualization, yes?
1215696755 M * Bertl (and replaces it)
1215696757 M * daniel_hozac yeah.
1215696769 M * daniel_hozac well, i haven't verified everything yet.
1215696775 M * Bertl okay, the migrate fails because?
1215696789 M * Bertl (entering that is)
1215696803 M * daniel_hozac well, something needs to be done either in the kernel or in userspace to allocated a new pid.
1215696816 M * daniel_hozac (post vc_enter_space(CLONE_NEWPID)
1215696849 M * Bertl okay, so we currently have a migration procedure, we can probably extend that to the pid space, but how to connect the task with the new pid?
1215696885 M * Bertl or should it happen on the enter_space?
1215696939 M * daniel_hozac i guess enter_space makes the most sense, since that's where it's being replaced.
1215696954 M * daniel_hozac (i.e. we have access to both pid namespaces there)
1215696990 M * daniel_hozac also, that patch needs some cleaning and probably quite a bit of locking/rcu_dereferenceing.
1215697008 M * daniel_hozac it's very rough right now, basically what's required to make it work on UP in very limited testing.
1215697307 Q * balbir Ping timeout: 480 seconds
1215697316 M * Bertl okay, well, a good start!
1215697336 M * Bertl I'm currently revisiting the xattr stuff
1215697399 M * daniel_hozac on XFS (and other broken filesystems?), or in general?
1215697439 M * Bertl in general, and with focus to broken filesystems
1215697533 J * tzanger ~tzanger@gromit.mixdown.ca
1215697578 M * daniel_hozac so what are you thinking? replacing them with an attribute, or just carving out our own fields in the inodes?
1215697796 M * Bertl currently I'm investigating both options
1215697982 J * balbir ~balbir@122.167.223.10
1215698410 M * Bertl okay, off for now .. bbl
1215698424 N * Bertl Bertl_oO
1215699227 M * _kwowt hm 
1215699234 M * _kwowt how much usable ip's is a /29 class?
1215699271 M * _kwowt :p
1215699280 M * phedny_ 2 ^ (32-29) - 2 = 6
1215699424 M * _kwowt thx :)
1215699451 M * _kwowt its like 8, but the first and the last isnt usable
1215699452 M * _kwowt right?
1215699455 M * phedny_ yes
1215699482 M * PowerKe and you might lose another one for the router depending on the setup
1215699547 M * _kwowt i got 91.185.202.0/29
1215699551 M * _kwowt that means .0 isnt usable
1215699553 M * _kwowt and .7 ?
1215699557 M * _kwowt i guess
1215699573 M * phedny_ true, .0 would be network address, .7 broadcast address
1215699592 M * phedny_ and what PowerKe said: you might need one for a router
1215699604 M * _kwowt yep
1215699964 M * z0d bbl
1215699967 Q * z0d Remote host closed the connection
1215700373 J * dowdle ~dowdle@scott.coe.montana.edu
1215700530 M * ruskie so what's the status of vserver on 2.6.24+ kernels? still experimental/beta/etc... ?
1215700644 M * daniel_hozac yes.
1215700768 M * ruskie :(
1215702092 N * Bertl_oO Bertl
1215702129 M * Bertl ruskie: you can help to change that by extensively testing it
1215703131 J * sebastiandeutsch ~sebastian@i538763A4.versanet.de
1215703143 J * fatgoose ~samuel@82.80.modemcable.oricom.ca
1215703382 J * sebastiandeutsch__ ~sebastian@i53876580.versanet.de
1215703529 J * sebastiandeutsch_ ~sebastian@i538766C7.versanet.de
1215703722 Q * sebastiandeutsch Ping timeout: 480 seconds
1215703867 Q * sebastiandeutsch__ Ping timeout: 480 seconds
1215703948 Q * _kwowt Read error: Connection reset by peer
1215704342 J * _kwowt ~quote@pomoc.ircnet.com
1215704358 M * _kwowt is it possible to run DNS (like bind) on guest vserver?
1215704405 M * _kwowt i'm using directadmin to control it, and i think i've set things right, but when i do a dns check it tells me 'Tried to fetch SOA record for domain, but DNS server ns1.si-shell.info [91.185.201.78] returned error code Refused'
1215704412 M * _kwowt CheckDNS received an answer to the query, but the answer indicates the error code mentioned. This means that remote DNS is ONLINE, but cannot give the answer for some reason.
1215704438 J * cryptronic ~oli@p54A3B20C.dip0.t-ipconnect.de
1215704456 M * _kwowt is that happening cuz of the vserver, or is just my dns config wrong?
1215704586 M * daniel_hozac your configuration is just wrong.
1215704777 Q * Aiken Remote host closed the connection
1215705245 M * sid3windr agreed :)
1215706277 J * bonbons ~bonbons@2001:960:7ab:0:2c0:9fff:fe2d:39d
1215706485 J * blizz ~stephan@e181079180.adsl.alicedsl.de
1215706843 P * sebastiandeutsch_ 
1215707118 Q * yarihm Quit: This computer has gone to sleep
1215707169 N * DoberMann DoberMann[PullA]
1215707529 Q * cryptronic Quit: Leaving.
1215708741 Q * pmenier_off Quit: Konversation terminated!
1215709251 M * _kwowt hm
1215709254 M * _kwowt bout the ipv6
1215709270 M * _kwowt To use the patch, you need util-vserver 0.30.212 or newer. These versions support IPv6 natively, so you just need to put the address in /etc/vservers/<guest>/interfaces/X/ip and start the guest to get it an IPv6 address.
1215709271 M * Bertl yes?
1215709304 M * _kwowt i need to put what address in 'ip' file?
1215709307 M * _kwowt ipv4?:)
1215709318 M * Bertl well, in the ipv6 case, the ipv6 one :)
1215709357 M * _kwowt right :P
1215709372 M * _kwowt so first i patch with http://people.linux-vserver.org/~bonbons/ipv6/patch-2.6.16.18-vs2.1.1rc21-ipv6a.diff
1215709383 M * _kwowt then add the ip and run the guest
1215709387 M * Bertl not needed if you got for a recent devel kernel
1215709397 M * Bertl s/got/go/
1215709397 M * _kwowt Latest version available: 0.30.215
1215709397 M * _kwowt       Latest version installed: 0.30.214
1215709419 M * daniel_hozac you're running a 2.6.16-vs2.1 kernel?
1215709420 M * _kwowt util-vserver
1215709426 M * _kwowt umm
1215709441 M * _kwowt Linux box2 2.6.20-vs2.2.0-gentoo 
1215709452 M * _kwowt on the host machine
1215709464 M * Bertl and on the guest? *G*
1215709483 M * daniel_hozac so that's really not the right patch.
1215709489 M * _kwowt Linux system.si-shell.net 2.6.20-vs2.2.0-gentoo 
1215709499 M * _kwowt woops
1215709537 M * _kwowt hm
1215709542 M * _kwowt uname -a returns me that?
1215709546 M * _kwowt on the guest
1215709548 M * _kwowt is that normal
1215709563 M * Bertl yep
1215709579 M * _kwowt oh
1215709613 M * _kwowt  patch-2.6.20-vs2.2.0.ipv6-pre4.diff
1215709614 M * _kwowt so this one
1215709641 M * daniel_hozac well, as Bertl mentioned, a 2.3 kernel already includes IPv6.
1215709641 M * Bertl I would probably try with the rc19 (one later)
1215709670 M * Bertl or, alternatively with a 2.3.x patch which includes ipv6 with all the fixes we did so far
1215709720 M * _kwowt so i either update the kernel or patch it
1215709732 M * daniel_hozac ... that's the same thing.
1215709744 M * _kwowt ok:)
1215709748 M * Bertl daniel_hozac: btw, did we end up with a solution for the class D issues?
1215709762 M * daniel_hozac i don't think so.
1215709766 M * daniel_hozac at least, not yet.
1215709790 M * Bertl okay, what I remember is, that we wanted to chavoid class D in collision checks ...
1215709798 M * daniel_hozac right.
1215709816 M * Bertl *avoid
1215709841 M * Bertl but the person who reported the issue disappeared again?
1215709926 M * daniel_hozac i guess so.
1215709942 M * daniel_hozac i don't remember who it was.
1215709983 M * Bertl okay, no big deal, I think I know somebody who will run into this issue shortly ... so it should get addressed soon
1215709999 M * _kwowt ok, i've patched the kernel
1215710020 M * _kwowt nowi need to change any options and recompile?
1215710132 M * _kwowt and what tha hell is
1215710137 M * _kwowt 1 out of 1 hunk FAILED -- saving rejects to file Makefile.rej
1215710160 M * Bertl that is probably not a problem ... (if it is the only one)
1215710178 M * _kwowt yes
1215710181 M * Bertl it means, that your kernel version is slightly different than the on used for this patch
1215710196 M * Bertl check in the Makefile.rej, it will show you a change to EXTRAVERSION, I guess
1215710257 M * _kwowt http://paste.linux-vserver.org/12309
1215710295 M * Bertl yep, harmless, you can add .ipv6 in your Makefile to reflect the change (manually)
1215710364 M * _kwowt hm
1215710395 M * _kwowt i guess it matters where i add it right?
1215710413 M * Bertl well, it will change how the kernel is reported
1215710450 M * Bertl (i.e. the name you got from the uname -a )
1215710588 M * _kwowt oh
1215710590 M * _kwowt EXTRAVERSION
1215710591 M * _kwowt here?
1215710966 Q * PowerKe Ping timeout: 480 seconds
1215711176 J * PowerKe ~tom@d5153A1EB.access.telenet.be
1215711192 M * _kwowt do i just recompile the kernel now
1215711201 M * _kwowt or any changes needed in config
1215711242 M * daniel_hozac well, is IPv6 enabled?
1215711332 M * _kwowt yes
1215711694 Q * kir Quit: Leaving.
1215713047 J * SpComb^_ terom@zapotek.paivola.fi
1215713197 J * ag-_ ~ag@fedaykin.roxor.cx
1215713198 J * transaci1 ~transacid@transacid.de
1215713199 Q * PowerKe resistance.oftc.net kilo.oftc.net
1215713199 Q * bonbons resistance.oftc.net kilo.oftc.net
1215713199 Q * eSa| resistance.oftc.net kilo.oftc.net
1215713199 Q * GuilhermeCunha resistance.oftc.net kilo.oftc.net
1215713199 Q * Wonka resistance.oftc.net kilo.oftc.net
1215713199 Q * transacid resistance.oftc.net kilo.oftc.net
1215713199 Q * phedny resistance.oftc.net kilo.oftc.net
1215713199 Q * Genghis resistance.oftc.net kilo.oftc.net
1215713199 Q * AndrewLee resistance.oftc.net kilo.oftc.net
1215713199 Q * SpComb resistance.oftc.net kilo.oftc.net
1215713199 Q * ag- resistance.oftc.net kilo.oftc.net
1215713202 J * phedny__ ~mark@2a02:348:35:5a26::1
1215713208 J * AndrewLee ~andrew@flat.iis.sinica.edu.tw
1215713220 J * PowerKe ~tom@d5153A1EB.access.telenet.be
1215713224 J * Wonka produziert@chaos.in-kiel.de
1215713320 J * Genghis ~Genghis@got.debian-inside.com
1215713348 N * Genghis Guest114
1215713350 N * SpComb^_ SpComb
1215713425 J * bonbons ~bonbons@2001:960:7ab:0:2c0:9fff:fe2d:39d
1215713425 J * eSa| ~kvirc@ip-87-238-2-45.static.adsl.cheapnet.it
1215713425 J * GuilhermeCunha ~Guilherme@189.30.49.33
1215713429 N * ag-_ ag-
1215713599 M * Bertl okay, off for now ... bbl
1215713604 N * Bertl Bertl_oO
1215714001 Q * docelic_ Quit: http://www.spinlocksolutions.com/
1215714648 Q * GuilhermeCunha Quit: Saindo
1215716536 J * Rankin ~sel@h165n3fls306o1052.telia.com
1215716672 M * Rankin I'm trying to use unfs3 inside a vserver, it works but it uses 100% of one cpu core. Has anyone seen this before? Distrubution: Debian/Etch Kernel: 2.6.21-2-vserver-686 unfs3 version:  0.9.15+dfsg-1
1215716842 M * daniel_hozac what's it doing?
1215716996 N * Guest114 Genghis
1215717028 N * Genghis Guest125
1215717111 M * Rankin As far I can see, it works as it should, but the cpu usage don't add up. If I do a 'ls'  in a folder with a couple of thousand files, the unfsd prosses uses 100% of one cpu core.
1215717157 M * daniel_hozac for how long?
1215717158 M * Rankin I've tried to do a strace on the proccess, but it don't semms to do anything unusual.
1215717319 M * Rankin 8k8 files, and a find . |wc -l uses 4 seconds
1215717354 M * daniel_hozac doesn't seem too unreasonable.
1215717496 M * Rankin but 100% cpu usage on the server don't seems reasonable
1215717519 M * Rankin at least not to me
1215717563 M * daniel_hozac so maybe unfs3 is not the way to go.
1215717608 M * Rankin do you have any other sugestion for a nfs server inside a vserver?
1215717627 M * daniel_hozac i can't really suggest NFS at all... :)
1215717656 M * Rankin Nor can I, but one don't always have a coice
1215718040 J * lilalinux ~plasma@80.69.41.3
1215718316 Q * _gh_ Ping timeout: 480 seconds
1215719157 Q * dowdle Remote host closed the connection
1215719808 N * DoberMann[PullA] DoberMann
1215719972 M * Rankin well, found that increasing the wsize and rsize parameter on the client increased the perfomance big time. 4x speedup, and the cpu usage on the server drop'ed significantly
1215719983 Q * loddafnir Quit: Leaving.
1215720019 J * frootat ~joern@dyndsl-091-096-061-082.ewe-ip-backbone.de
1215720121 M * Rankin Or maybe not, caching fooled me..
1215720271 Q * phedny_ Ping timeout: 480 seconds
1215720309 J * yarihm ~yarihm@84-74-147-84.dclient.hispeed.ch
1215720656 N * Guest125 Genghis
1215720688 N * Genghis Guest133
1215720862 J * frootat_ ~joern@dyndsl-091-096-039-094.ewe-ip-backbone.de
1215721146 Q * frootat Ping timeout: 480 seconds
1215721158 N * frootat_ frootat
1215721396 Q * lilalinux Remote host closed the connection
1215721650 Q * blizz Quit: Lost terminal
1215722830 Q * sladen Ping timeout: 480 seconds
1215723225 J * mire ~mire@8-168-222-85.adsl.verat.net
1215724316 N * Guest133 Genghis
1215724349 N * Genghis Guest145
1215724382 Q * bonbons Quit: Leaving
1215725619 Q * frootat Quit: :(){ :|:&};:
1215727337 J * dna_ ~dna@132-202-dsl.kielnet.net
1215727401 N * DoberMann DoberMann[ZZZzzz]
1215727421 J * fafa_ ~fafa@p5496CD1D.dip.t-dialin.net
1215727496 N * Bertl_oO Bertl
1215727524 M * Bertl back now ...
1215727732 Q * dna Ping timeout: 480 seconds
1215727836 Q * the_fafa Ping timeout: 480 seconds
1215727936 Q * dna_ Quit: Verlassend
1215727976 N * Guest145 Genghis
1215728009 N * Genghis Guest156
1215728467 J * darkpsi ~no@72-48-199-234.dyn.grandenetworks.net
1215728470 J * _gh_ ~gerrit@c-67-169-199-103.hsd1.or.comcast.net
1215728482 M * darkpsi geez
1215728495 M * darkpsi bind inside a vserver is hanging the whole system!
1215728508 M * darkpsi not shutting down the network, or binding wrong
1215728512 M * darkpsi just hanging the machine
1215728539 M * darkpsi machine pings, but can't ssh or do anything
1215728554 M * darkpsi it's not always the precise same hang, sometimes SOME functionality is available
1215728564 M * darkpsi but eventually, when I try to STOP bind in a vserver, the machine hangs
1215728574 M * darkpsi but still pings
1215728601 M * darkpsi anyone had the same experience?
1215728721 M * darkpsi hmm, although a vserver <name> stop hangs indefinitely, and doesn't respond to CTRL-C/CTRL-Z/CTRL-D< eventually it DOES
1215728728 M * darkpsi CTRL-Z suspended the vserver-sotp
1215728752 M * darkpsi ifconfig (in the host) is now hanging indefinitely
1215728771 M * darkpsi and not responding to CTRL-Z/D/C either
1215728959 M * darkpsi don't mean to be rude, but out of 100+ memmers, nobody responds?
1215728967 M * PowerKe you mean bind, the dns server?
1215728980 M * darkpsi yes.
1215728981 M * darkpsi named
1215728982 M * PowerKe and vtop doesn't show anything?
1215728990 M * darkpsi the machine is barely useable.
1215729010 M * PowerKe I can only say I haven't had any problems using bind in a vserver yet
1215729014 M * darkpsi i can't get back in (it's hosted remotely) and my net is now down..
1215729037 M * darkpsi vserver <name> stop hung for a while, but eventually accpeted a CTRL-Z
1215729053 M * PowerKe you're sure it's a software problem and not a bad network connection?
1215729060 M * darkpsi the next command i typed was ifconfig,. on the off chance this is a net issue (but machine pings)
1215729072 M * darkpsi now, if config is hung completely.
1215729079 M * darkpsi not taking CTRL-C or CTRL-Z
1215729114 M * daniel_hozac what kernel are you using?
1215729119 M * darkpsi yes, i'm sure the nic is okay.  built the entire system manually using a makefile & about 100 wgets
1215729133 M * darkpsi so the system is sane enough to compile itself & get to the world.
1215729210 M * darkpsi kernel ver is 2.6.20, vs is 2.2.0
1215729232 M * darkpsi bind is 9.4.2
1215729271 M * darkpsi ifconfig cdoesn't seem to want out of the noose
1215729300 M * darkpsi i have a hunch the loopback interface is getting screwed somehow
1215729303 M * darkpsi but it's just a hunch
1215729308 M * darkpsi pinging from outside works
1215729328 M * darkpsi but ssh from outside doesn't (hangs)
1215729344 M * PowerKe If you get the chance I'd check dmesg / the syslog just to be sure
1215729371 M * PowerKe allthough it doesn't explain why ping still works in that case...
1215729402 M * daniel_hozac ping is a service provided by the kernel.
1215729409 M * darkpsi i'm about to try ssh w/o creating a pty
1215729420 M * darkpsi ssh -v is showing some dialog, so the machine isn't utterly unresponsive
1215729599 M * darkpsi well
1215729608 M * darkpsi there's been a slight change in SSH's behaviour
1215729625 M * darkpsi prior to trying ssh -vt  (verbose, not psuedoy-tty)
1215729638 M * darkpsi ssh -v was showing quite a lot of response, but never asking for password
1215729674 M * darkpsi now however, ssh -v  (with or without the -T) only shows a few lines, and then closes the connection at ssh_exchange_identification
1215729691 M * darkpsi ifconfig (on an already connected ssh) is still hanging
1215729699 M * darkpsi pinging still works
1215729703 M * PowerKe Have you tried using ping with larger packet sizes?
1215729797 M * darkpsi just tried 1000 increments up to 10000, works
1215729849 M * darkpsi gets slower as size increases (expected) and at -s 10000, some pongs never arrive
1215729855 M * daniel_hozac darkpsi: you might want to try a recent kernel...
1215729879 M * darkpsi agreed.
1215729893 M * darkpsi unfortunately, i'm at the mercy of AuFS
1215729906 M * daniel_hozac that seems self-imposed...
1215729936 M * darkpsi :)
1215729967 M * darkpsi AuFS isn't clear about wether vserver support exists at newer versions
1215729984 M * daniel_hozac why do you need it?
1215729998 M * daniel_hozac are you running off of a CD?
1215730002 M * darkpsi Building the vservers in stacks, like wedding cakes.
1215730010 M * darkpsi mind you, this works swimingly on a gentoo system
1215730017 M * daniel_hozac and hardlinks don't work, because...?
1215730031 M * darkpsi this is a union filesystem
1215730042 M * daniel_hozac i know.
1215730049 M * darkpsi it's for a different purpose.
1215730055 M * daniel_hozac not really.
1215730119 M * darkpsi i appreciate your sentiment; but this is a configuration issue between me, vserver, and bind
1215730152 M * daniel_hozac or so you think.
1215730161 M * PowerKe I'm running bind-9.4.1_p1 on 2.6.20-vs2.2.0-gentoo
1215730165 M * daniel_hozac have you straced ifconfig to see if the binary is even getting execed?
1215730185 M * daniel_hozac PowerKe: aren't you supposed to run at least 9.4.2-p1 to be safe?
1215730188 M * darkpsi bind in a vserver on the identical kernel version, vserver version, and aufs (stacked many levels deep) worked under gentoo
1215730217 M * darkpsi a major difference however, is my gentoo is an x86_32, this server is an x86_64
1215730219 M * PowerKe daniel_hozac: probably, allthough I doubt anyone's going to take the effort to poison my cache
1215730290 M * darkpsi no, haven't execd ifconfig
1215730294 M * darkpsi er straced it
1215730301 M * darkpsi about to put in a manual reboot request w/ host
1215730324 M * darkpsi so, until I start/stop bind, i'll have the machine back
1215730333 M * darkpsi as I said, this doesn't happen every time i start and stop bind either
1215730339 M * darkpsi only most of the time
1215730398 M * darkpsi now we wait :)
1215730408 M * darkpsi so. as for bind 9.4.2
1215730415 M * PowerKe compiling 9.4.2_p1 now
1215730418 M * darkpsi i'll happily upgrade any part of the systme I can.
1215730437 M * darkpsi 9.4.2-p1...
1215730449 M * darkpsi is the only change a cache bug fix, or something relevant to vserver?
1215730480 M * darkpsi i've read through the vserver docs on bind/named, and it's description doesn't seem to apply here although it could
1215730517 M * darkpsi obviously, i compiled it myself without caps, but WITH --enable-threads
1215730531 M * darkpsi and named -u named starts ok
1215730744 M * daniel_hozac you can build it with caps if you want.
1215730745 M * darkpsi okay, looked at bin 9.4.2-p1
1215730757 M * darkpsi seems to be an unrelated fix.
1215730894 M * PowerKe running 9.4.2-P1 now (USE flags ipv6 and ssl)
1215731008 M * darkpsi (still waiting for reboot)
1215731018 M * darkpsi they call it 'remote hands and eyes service'
1215731030 Q * FloodServ Service unloaded
1215731031 M * darkpsi i asked 'em how much extra for "remote fists of fury service"
1215731036 N * Guest156 Genghis
1215731046 M * PowerKe :)
1215731046 M * daniel_hozac you know most modern systems have remote management built-in, right?
1215731071 M * darkpsi yeah, this host ads a net-kvm as an upcharge
1215731086 M * darkpsi i'm gonn have to pay for it for a while until i get these issues resolved
1215731141 M * darkpsi there MAY be a way to get kernel net console & some bios tweaks to result in effectively remote console
1215731149 M * darkpsi haven't tried yet...
1215731153 M * PowerKe I have remote reboot via web panel in my basic package. Manual power cycle is also included, but only during business hours and might take 15 minutes
1215731164 M * darkpsi aha
1215731189 M * Bertl darkpsi: if you have more than one server, you probably don't need any 'external' console stuff or hands-on
1215731189 M * darkpsi well, these guys, The Planet, are 24/7, but yes. remote reboot @ 15 minutes is typical
1215731218 M * Bertl just connect the serial ports of two machines (daisy chain for more machines) 
1215731245 M * Bertl put a panic=60 in the boot line and make sure that magic sysrq is enabled
1215731247 Q * mire Ping timeout: 480 seconds
1215731263 M * darkpsi thanks bertl, i have three identical 3.6GHz P4's, and i WILL be cross connecting them and maybe even serial consoling them--which sounds like what you're suggesting
1215731297 M * darkpsi i know, i know
1215731309 M * darkpsi (but i appreciate it nonetheless)
1215731350 M * Bertl if M$ hadn't taken over the pc/server sector, we would have bios based serial/network consoles everywhere
1215731370 M * Bertl hell we wouldn't have bios, we would have firmware :)
1215731376 M * darkpsi how many shameful statements start with "if M$ hadn't..."
1215731421 M * darkpsi heh
1215731452 M * darkpsi okay, got my reboot
1215731472 M * darkpsi btw, daniel, have you tried vserver+aufs?
1215731483 M * darkpsi i HAVE tried vhashify/unify
1215731588 M * darkpsi before i bash my head into the wall a third time, what has proven to be the best solution to the loopback inside vserver prob?
1215731611 M * daniel_hozac uh, using a kernel that supports it?
1215731647 M * darkpsi you're referring to a newer vserver patch, no?
1215731652 M * Bertl darkpsi: loopback as in the loop (disk) device or as in lo (network)?
1215731652 J * FloodServ services@services.oftc.net
1215731658 M * darkpsi lo
1215731666 M * darkpsi it's a suspicion of mine
1215731666 N * Genghis Guest2
1215731678 M * darkpsi heh Gengis
1215731678 M * Bertl darkpsi: what's the problem there for you?
1215731694 M * darkpsi well, as I said, stopping a bind inside a vserver hangs the whole machine
1215731714 M * darkpsi i suspect it may be bringing down the loopback iface on the masters, so I want to ensure that doesn't happen (to eliminate that possibility)
1215731742 M * Bertl kernel version/patch and your interfaces config?
1215731781 M * darkpsi linux-2.6.20+vs-2.2.0+aufs
1215731807 M * Bertl actually 2.2.0? or 2.2.0.x, if so, what is x
1215731811 M * darkpsi ifaces on master is eth1 and lo
1215731815 M * darkpsi (eth0 is unused)
1215731822 M * Bertl master means host?
1215731828 M * darkpsi ifaces on vserver is a single eth0, 10.42.0.1
1215731840 M * darkpsi iptable SNAT for packet traversal
1215731845 M * darkpsi yes.
1215731849 M * darkpsi master means host
1215731854 M * darkpsi (host is such an overused word)
1215731859 M * darkpsi then so is master
1215731866 M * darkpsi let's say.. 'vhive'  ;)
1215731877 M * Bertl yes, master ... let me be your host here :)
1215731915 M * Bertl but yes, vhive sounds cool, you should have suggested that 7 years ago
1215731925 M * darkpsi checking on subversions
1215731933 M * darkpsi another reserved word
1215732009 M * darkpsi well, when i get this happy & stable, i'll publish my woes (and workarounds) for all to see.
1215732016 J * Aiken ~james@ppp121-45-243-126.lns2.bne4.internode.on.net
1215732018 M * darkpsi vserver+aufs is REAL nice when it works
1215732034 M * darkpsi vunify hurts my head
1215732070 M * darkpsi and there are lots of reaons not to use hardlinks that way
1215732079 M * Bertl aha, like?
1215732083 M * darkpsi won't go into that or i'll get stabbed by the guys who wrote it
1215732110 M * darkpsi well, try getting sensible answers from a du in ALL cases, for one
1215732116 M * Bertl well, I think I won't stab you, and I doubt daniel_hozac will :)
1215732116 M * darkpsi really, don't make me do this
1215732134 M * darkpsi ah, i see
1215732153 M * darkpsi if you haven't tried aufs, it's a dream come true
1215732156 M * daniel_hozac du does what it should.
1215732177 M * Bertl darkpsi: could you do a simple check for me with aufs?
1215732185 M * darkpsi ?
1215732194 M * darkpsi chattr won't work of course
1215732199 M * darkpsi then it shouldn't
1215732235 M * Bertl you have a read-only 'template' and a read/write overlay, yes?
1215732251 M * darkpsi yes, about 6 pairs of them on the gentoo machine
1215732290 M * Bertl okay, could you create a single file for me on the template like this: echo "five" >five.txt
1215732304 M * darkpsi i686.gentoo.org -> gentoo.org -> gentoo.mcd (my initials) -> mcd -> asterisk.i686.mcd -> 
1215732310 M * darkpsi and so on
1215732334 M * darkpsi that's not for production, but for development uses of cours on a prod environment it'll be collapsed somewhat or completely.
1215732353 M * darkpsi one sec.
1215732365 M * Bertl then, in two different overlays, do 'll -i five.txt'
1215732380 M * Bertl (or overlay and template, doesn't matter)
1215732445 J * trippeh_ atomt@uff.ugh.no
1215732477 M * Bertl ah, even better, do a 'stat five.txt' and upload it please
1215732499 M * Bertl (in two different overlays or overlay/template)
1215732519 Q * _gh_ Ping timeout: 480 seconds
1215732524 M * trippeh_ Is ipv6 supported in guests with 2.3 without extra patches yet?
1215732528 M * darkpsi okay, to make sure i follow you
1215732532 M * Bertl trippeh_: yep
1215732552 M * trippeh_ Hurrah :)
1215732581 Q * yarihm Quit: Leaving
1215732600 M * daniel_hozac has been since the beginning of 2.3, pretty much.
1215732603 M * darkpsi echoed on template.
1215732620 M * darkpsi now stating on (mount of overlay+template)
1215732626 M * Bertl exactly
1215732627 M * darkpsi and then statting on a mount of THAT mount
1215732655 M * Bertl well, either template + overlay or two _separate_ overlays on the same template
1215732677 M * Bertl like, two different guests, using the same base template
1215732691 M * darkpsi hmm
1215732705 M * darkpsi okay. that's not quite what I thought you mena,t but no prob.
1215732716 M * Bertl if you don't have such a setup, template and overlay is fine for me
1215732726 M * darkpsi first off, heres the stat on the "base" five.txt
1215732745 M * darkpsi # stat five.txt
1215732746 M * darkpsi   File: `five.txt'
1215732746 M * darkpsi   Size: 5               Blocks: 8          IO Block: 4096   regular file
1215732746 M * darkpsi Device: 902h/2306d      Inode: 21790721    Links: 1
1215732746 M * darkpsi Access: (0664/-rw-rw-r--)  Uid: (    0/    root)   Gid: (    0/    root)
1215732746 M * darkpsi Access: 2008-07-10 18:29:55.000000000 -0500
1215732746 M * darkpsi Modify: 2008-07-10 18:29:55.000000000 -0500
1215732748 M * darkpsi Change: 2008-07-10 18:29:55.000000000 -0500
1215732802 M * darkpsi >>> and, here's a stat on another aufs mount above that:
1215732802 M * daniel_hozac please use paste.linux-vserver.org for anything longer than 3 lines.
1215732803 M * darkpsi # stat five.txt
1215732803 M * darkpsi   File: `five.txt'
1215732803 M * darkpsi   Size: 5               Blocks: 8          IO Block: 4096   regular file
1215732803 M * darkpsi Device: 1fh/31d Inode: 23          Links: 1
1215732803 M * darkpsi Access: (0664/-rw-rw-r--)  Uid: (    0/    root)   Gid: (    0/    root)
1215732804 M * darkpsi Access: 2008-07-10 18:29:55.000000000 -0500
1215732804 M * darkpsi Modify: 2008-07-10 18:29:55.000000000 -0500
1215732806 M * darkpsi Change: 2008-07-10 18:29:55.000000000 -0500
1215732819 M * darkpsi okay.
1215732823 M * Bertl ah, yeah, as I expected (yeah, pastbin would have been better)
1215732832 M * darkpsi what we looking for?
1215732835 M * Bertl you see the difference in inode/device
1215732842 M * darkpsi that's on an x86_32 gentoo system working fine
1215732850 M * darkpsi yes
1215732860 M * darkpsi 902 versus 1f
1215732862 M * Bertl that means, that if you have, let's say 50 debian guests
1215732878 M * darkpsi i'm not gonna get codeseg sharing, huh?
1215732902 M * Bertl neither that, nor any benefits from inode caches and such
1215732907 M * darkpsi drat
1215732919 M * darkpsi that's one major reason for doing it this way (of course)
1215732929 M * Bertl that's one reason why you might _want_ hard links after all :)
1215732939 M * darkpsi aufs is far from perfect, and was recently broken (later cvs pulls won't build) and seems to be a lonewolf project
1215732942 M * darkpsi we need something better!
1215732966 M * Bertl trust me, I've been down that path, and did a lot of investigating
1215733000 M * Bertl the results so far are: unionfs/aufs/whatever is a good choice if you have a cd/dvd based distro
1215733024 M * Bertl hardlinks are a good choice if you have shared contents
1215733070 M * Bertl I'm not saying that a good overlayfs isn't doable
1215733080 M * darkpsi (or preferrable :) )
1215733110 M * Bertl but it is _very_ complicated to get right for scenarios like we are dealing with .. and it's almost impossible to get it perfect :)
1215733176 J * _gh_ ~gerrit@c-67-169-199-103.hsd1.or.comcast.net
1215733183 M * Bertl here are the basic feature requirements to make it good (not perfect :)
1215733194 M * darkpsi go one.
1215733196 M * darkpsi er on
1215733203 M * Bertl - identical/mapped files need to be presented with the same filesystem/inode id
1215733205 M * darkpsi i'l there.  i'll help write it, time permitting
1215733236 M * darkpsi i NEEDS to be done
1215733236 M * darkpsi agreed.
1215733238 M * Bertl - negative entries (Dentry like) need to be performant and space efficient
1215733251 M * darkpsi the so-called whiteouts
1215733289 M * Bertl - files/dirs which drift apart and come together lateron need to be 'mapped back'/optimized away
1215733314 M * darkpsi agreed.
1215733328 M * darkpsi noticed weirdness in that arena, especially when i make a change on a submount
1215733329 M * Bertl - layer indirection must be unnoticeable
1215733342 M * darkpsi and then choose to make that change at a higher level
1215733351 M * darkpsi whiteouts have to be manually eliminated
1215733374 M * darkpsi layer indirection unnoticeable ?  explain..
1215733378 M * Bertl now, most of the currently available solutions do not even handle the negative entries properly, not to speak of the rest
1215733420 M * darkpsi what would you consider "proper" for whiteouts?  4k per file is defintely NOT, with you there.
1215733423 M * Bertl that means, if you access a file, you will have a duplicate layer traversal, i.e. the file gets accessed in the overlay fs, which _relays_ requests to the 'base' fs
1215733461 M * Bertl a directory entry would be exceptabe for negative entries
1215733471 M * Bertl *acceptable
1215733495 M * darkpsi okay. realying as you say would make fuse & etc work quite nice.
1215733515 M * Bertl now, the unification Linux-VServer does, handles basically all the abovementioned points quite nicely
1215733520 M * darkpsi i believe aufs is close there, but seems to have some arbitrary restrictions that would disappear with the correct abstraction
1215733558 M * Bertl I doubt we'll ever see an overlay fs which addresses the first point
1215733583 M * darkpsi by "quite nicely" you surely don't mean MD5 summing all files into a giant nasty spaghetti bowl of hash entries...
1215733613 M * darkpsi i mean.. i know you did what you had to do...
1215733614 M * daniel_hozac that's an implementation detail. why do you care?
1215733619 M * Bertl simply because that is too much efford (implementation wise)
1215733637 M * darkpsi well, im interested not only in space saving
1215733662 M * Bertl darkpsi: okay, what _are_ you interested in?
1215733663 M * darkpsi but in being able to isolate overlays instantaneously, and with nothing more complex than TAR
1215733699 M * darkpsi and of course, codeseg and data sharing in memory is a must.
1215733710 M * darkpsi i want 1000 apaches running in the memory footprint of oone
1215733717 M * Bertl but you don't get that from the aufs
1215733723 M * darkpsi nope, you are right
1215733745 M * darkpsi until your spaking, i hadn't realized that.
1215733752 M * darkpsi spanking
1215733788 M * Bertl the 'separation' in the unification case is quite simple too, just use rsync/rdiff to get the 'delta' between template and guest
1215733808 M * Bertl tools are even optimized to handle the hardlink case there
1215733852 M * Bertl further, there is no additional layer (unless you write to a 'shared' file) between userspace and the filesystem
1215733864 M * Bertl (thus eliminating all overhead there)
1215733903 M * Bertl and, finally, you can eliminate 'grown duplicates' at any point
1215733916 Q * _gh_ Ping timeout: 480 seconds
1215733941 M * Bertl so, what was the advantage of an unionfs again?
1215733962 M * darkpsi :P
1215733984 M * darkpsi it's a bear, and it's an ugly one at that
1215734003 M * Bertl don't get me wrong, we are perfectly fine if you want to use it ... we are not against such setups per se
1215734022 M * darkpsi well, i'm miffed about the inode renumbering
1215734035 M * darkpsi so miffed i'd be willing to fix aufs for the purpose
1215734052 M * darkpsi it really should be a trivial thing to stack filesystems
1215734092 M * daniel_hozac umm, no.
1215734095 M * Bertl I think you are underestimating the implementation challenges there .. but feel free to prove me wrong :)
1215734103 M * darkpsi the major problem, is of course, locking (concurrent access)
1215734135 M * daniel_hozac there are pretty well-defined semantics for that. there are far more interesting problems to solve...
1215734153 M * Bertl like merging inode spaces/numbers :)
1215734167 M * darkpsi well.. why merge?
1215734209 M * Bertl because that's what you have to do when you want to present identical inodes as identical to the vfs
1215734213 M * darkpsi how come it can't simply pass through...  (i can see one reason; some filesystems won't have "inodes" per se)
1215734244 M * Bertl no, the problem is, that you have a mounted filesystem, with its own inode numbering
1215734267 M * Bertl if you have, e.g. 10 guests using overlays
1215734280 M * Bertl then they would have to 'see' the same filesystem and inodes
1215734310 M * Bertl but as result of the 10 different mounts, they see 10 different filesystems, with 10 'different' inodes
1215734331 M * Bertl which get 'mapped' to the same (11th, inode on _another_ filesystem)
1215734342 M * darkpsi this sounds like an in the box/ out of the box problem
1215734356 J * sebastiandeutsch ~sebastian@i53876573.versanet.de
1215734362 M * darkpsi you COULD make a fuse module which allowed unioning like this under itself without such limitations
1215734377 M * darkpsi ONLY under itself, however
1215734387 M * darkpsi i.e., the template and overlay would have to be managed by it