1192752148 Q * jescheng Remote host closed the connection
1192752165 J * jescheng ~jescheng@proxy-sjc-2.cisco.com
1192752315 M * daniel_hozac after stopping all the guests, i'm down to 5 namespaces.
1192752363 M * Bertl hmm, maybe kernel threads spawned from inside namespaces?
1192752611 M * daniel_hozac shouldn't the mount show up in that process's /proc/<pid>/mounts in that case?
1192752638 M * brc Bertl: Ok! So there is nothing to do on this reboot ?
1192752644 M * brc i mean before the reboot
1192752675 M * Bertl brc: except for the kernel changes (debug)
1192752852 M * daniel_hozac Bertl: hmm, i guess i know what triggers it.
1192752865 M * Bertl let's hear ...
1192752880 M * daniel_hozac i just remembered vrpm/vyum do some namespace trickery, and running just vrpm ... -- -qa increases it by one.
1192752911 M * Bertl aha, hmm, can we break that down into syscall commands?
1192752923 M * daniel_hozac i'll try.
1192753156 M * jescheng do I need to set some config in order to fwd the environment from host->vserver when doing vserver exec?
1192753202 M * jescheng Because I still see the problem when running vserver exec (after setting host LD_LIBRARY_PATH to vserver library path)
1192753240 M * daniel_hozac so what's the exact command you're running?
1192753312 M * jescheng vserver ntop exec "/bin/ls"
1192753339 M * jescheng and i get error "vcontext: execvp("/bin/ls"): No such file or directory
1192753362 M * jescheng the files is there
1192753364 M * Bertl jescheng: maybe a missing library or a bad barrier?
1192753382 M * daniel_hozac and you did export LD_LIBRARY_PATH, right?
1192753384 M * daniel_hozac what's it set to?
1192753403 M * jescheng Bertl: well this is what I did, I moved /lib in the vserver to /lib.bak
1192753415 M * jescheng Bertl: Before the move, i can exec "/bin/ls" fine, but after it does not work
1192753437 M * Bertl and LD_LIBRARY_PATH contains`
1192753443 M * Bertl s/`/?
1192753463 M * jescheng daniel_hozac: the LD_LIBRARY_PATH=/home/vservers/ntop/lib.bak
1192753478 M * Bertl ah, well, that won't work
1192753492 M * daniel_hozac you need to have the path from the guest's perspective, i.e. /lib.bak
1192753493 M * Bertl try LD_LIBRARY_PATH=/lib.bak
1192753507 M * jescheng oh!
1192753594 M * Bertl daniel_hozac: I feel a nap coming up ... if you get some syscall data, please notify me (will check it in a few hours)
1192753620 M * Bertl back later ...
1192753622 M * daniel_hozac np, i might not get it before tomorrow.
1192753628 N * Bertl Bertl_zZ
1192753722 M * jescheng hmm, i set it to /lib.bak, but still same error
1192753921 M * daniel_hozac and, you did export LD_LIBRARY_PATH, right?
1192754073 M * jescheng yea
1192754133 M * daniel_hozac well, you might want to try with another directory. /lib is usually hardcoded into binaries.
1192754732 M * jescheng I tried with the PATH var ...looks like that get's inherited, but with LD_LIBRARY_PATH still a problem for me
1192754787 M * daniel_hozac so what's the test that is failing for you?
1192755050 J * raa ~raa@207.114.230.7
1192755696 Q * raa Quit: Leaving
1192756418 Q * ensc Ping timeout: 480 seconds
1192756418 Q * Guest2009 Read error: Connection reset by peer
1192756701 J * Guest2104 ~ensc@www.sigma-chemnitz.de
1192756851 Q * infowolfe Read error: Connection reset by peer
1192758108 J * ensc ~irc-ensc@p54B4FEE2.dip.t-dialin.net
1192760456 Q * hparker Quit: peer reset by connection
1192760761 M * jescheng daniel_hozac: got it working on another bash shell.... using same step. maybe i just had a bad shell.
1192760782 M * jescheng any, just want to let you know. I'm off, thanks for your help!
1192760786 Q * jescheng Quit: Leaving
1192765688 Q * Julius Ping timeout: 480 seconds
1192766860 Q * zLinux Remote host closed the connection
1192771050 Q * mountie Ping timeout: 480 seconds
1192771691 J * sharkjaw ~lgab@shell.ormset.no
1192772342 Q * Hollow Remote host closed the connection
1192772352 J * Hollow ~hollow@proteus.croup.de
1192772995 J * DavidS ~david@vpn.uni-ak.ac.at
1192773332 J * ntrs__ ~ntrs@79.125.248.175
1192774464 J * virtuoso_ ~s0t0na@ppp91-122-94-46.pppoe.avangard-dsl.ru
1192774870 Q * virtuoso Ping timeout: 480 seconds
1192774891 J * ntrs_ ~ntrs@79.125.252.183
1192775227 Q * ntrs__ Ping timeout: 480 seconds
1192775495 Q * ntrs_ Ping timeout: 480 seconds
1192775733 J * yang yang@yang.netrep.oftc.net
1192776597 N * ensc Guest2136
1192776607 J * ensc ~irc-ensc@p54B4E44F.dip.t-dialin.net
1192776713 Q * Guest2136 Ping timeout: 480 seconds
1192777236 J * larsivi ~larsivi@85.221.53.194
1192777506 J * JonB ~NoSuchUse@0x5739c8b4.roennqu1.broadband.tele.dk
1192777900 Q * JonB Quit: This computer has gone to sleep
1192778138 J * JonB ~NoSuchUse@0x5739c8b4.roennqu1.broadband.tele.dk
1192778841 J * gebura ~gebura@77.192.186.197
1192779239 J * Piet ~piet@tor.noreply.org
1192779283 Q * Piet Remote host closed the connection
1192779334 J * Piet ~piet@tor.noreply.org
1192779422 J * dna ~dna@181-208-dsl.kielnet.net
1192782351 J * Julius ~julius@p57B24B6D.dip.t-dialin.net
1192782748 Q * JonB Quit: This computer has gone to sleep
1192782863 Q * Aiken resistance.oftc.net scorpio.oftc.net
1192782863 Q * mattzerah resistance.oftc.net scorpio.oftc.net
1192783018 Q * Julius Ping timeout: 480 seconds
1192783590 J * Aiken ~james@ppp121-45-206-11.lns1.bne1.internode.on.net
1192783590 J * mattzerah ~matt@121.50.219.188
1192783729 J * Julius ~julius@p57B24B6D.dip.t-dialin.net
1192783995 J * lilalinux ~plasma@dslb-084-058-216-052.pools.arcor-ip.net
1192785349 J * ntrs_ ~ntrs@79.125.252.183
1192786852 J * JonB ~NoSuchUse@0x535f65c3.kjnxx7.adsl-dhcp.tele.dk
1192787134 Q * sharkjaw Quit: Leaving
1192787157 J * sharkjaw ~lgab@shell.ormset.no
1192787997 Q * PhatJ Quit: PhatJ
1192788044 J * Ben81 ~Ben81@tipi0e.lri.fr
1192788053 P * Ben81 
1192789557 Q * ntrs_ Ping timeout: 480 seconds
1192789931 J * click click@ti511110a080-2283.bb.online.no
1192790313 Q * DavidS Quit: Leaving.
1192790499 Q * sharkjaw Remote host closed the connection
1192791548 J * ftx ~ftx@dslb-084-060-236-121.pools.arcor-ip.net
1192791567 Q * JonB Quit: This computer has gone to sleep
1192792491 Q * FireEgl Read error: Connection reset by peer
1192792500 J * JonB ~NoSuchUse@0x535f65c3.kjnxx7.adsl-dhcp.tele.dk
1192792941 J * Linus ~Lucifer@bl7-134-112.dsl.telepac.pt
1192793040 M * brc bertl, i am almost sure it has to do with vserver restart
1192793056 M * brc One of the clients cancelled the server so i did soem tests on his vps, i could stop/start without problems
1192793064 M * brc but i think that if i restart it will "lock"
1192793211 Q * JonB Quit: This computer has gone to sleep
1192793304 J * JonB ~NoSuchUse@0x535f65c3.kjnxx7.adsl-dhcp.tele.dk
1192793334 J * FireEgl FireEgl@2001:5c0:84dc:1:91ed:155:f1e0:ed1
1192793493 Q * ftx Remote host closed the connection
1192793562 J * ftx ~ftx@dslb-084-060-236-121.pools.arcor-ip.net
1192794559 Q * dna Quit: Verlassend
1192794836 Q * Linus Remote host closed the connection
1192794995 Q * Julius Ping timeout: 480 seconds
1192795290 J * Julius ~julius@p57B24B6D.dip.t-dialin.net
1192796627 Q * speedy Quit: [BX] I came, I saw, I ran away screaming
1192796628 J * ntrs_ ~ntrs@79.125.252.183
1192796737 J * ema ~ema@rtfm.galliera.it
1192796772 J * meandtheshell ~markus@85.127.114.128
1192796859 Q * Aiken Quit: Leaving
1192797262 Q * meandtheshell Quit: Leaving.
1192797326 J * meandtheshell ~markus@85.127.114.128
1192798611 J * CWC ~CWC@89-215-37-177.2073053861.ddns-lan.pl.ekk.bg
1192798912 J * yarihm ~yarihm@whitehead2.nine.ch
1192799259 Q * CWC Quit: Client exiting
1192799270 J * CWC ~CWC@89-215-37-177.2073053861.ddns-lan.pl.ekk.bg
1192799381 Q * CWC 
1192799550 Q * JonB Quit: This computer has gone to sleep
1192800135 J * JonB ~NoSuchUse@0x535f65c3.kjnxx7.adsl-dhcp.tele.dk
1192800749 Q * epicbjorn Ping timeout: 480 seconds
1192800843 J * lilalinux_ ~plasma@dslb-084-058-252-053.pools.arcor-ip.net
1192801183 J * dreamind ~dreamind@p54A78877.dip0.t-ipconnect.de
1192801217 Q * lilalinux Ping timeout: 480 seconds
1192801221 N * dreamind Guest2155
1192801298 Q * larsivi Quit: Konversation terminated!
1192801664 M * Guest2155 Hi folks
1192801666 M * Guest2155 oh well
1192801669 M * JonB hi
1192801675 N * Guest2155 dreamind
1192801681 M * dreamind thats better
1192801684 M * dreamind hi JonB 
1192801862 Q * JonB Quit: This computer has gone to sleep
1192802649 Q * gebura Quit: Quitte
1192802933 J * JonB ~NoSuchUse@0x535f65c3.kjnxx7.adsl-dhcp.tele.dk
1192803684 Q * JonB Quit: This computer has gone to sleep
1192803771 M * snooze does the vserver patch make any changes to code handling file systems and likewise?
1192803829 J * alex_ ~joe@62-249-237-101.no-dns-yet.enta.net
1192803830 M * alex_ hi!
1192803837 M * alex_ im getting this error whilst in a guest:
1192803845 M * alex_ apache2: apr_sockaddr_info_get() failed for oor
1192803846 M * alex_ normal?
1192804027 J * coderanger_ ~coderange@x-15-06.dynamic2.rpi.edu
1192804070 Q * ntrs_ Ping timeout: 480 seconds
1192804098 M * daniel_hozac snooze: meaning?
1192804109 M * daniel_hozac alex_: means that you haven't setup /etc/hosts properly.
1192804158 M * snooze daniel_hozac: well with the vserver patch on one of my boxes linux cant mount root
1192804187 M * daniel_hozac and you created that kernel the _exact_ same way you create vanilla kernels, yes?
1192804192 M * snooze yep
1192804195 M * daniel_hozac based on the same version?
1192804246 M * snooze uhm well, i tested vanilla 2.6.22.6 and 2.6.22.6 with vserver+grsec (not working), and also 2.6.22.9 (not working)
1192804264 M * snooze 2.6.22.9 was with vserver i meant
1192804274 M * daniel_hozac and you use the same config?
1192804278 M * snooze yeah
1192804314 M * daniel_hozac sounds like you're just forgetting some step.
1192804315 M * snooze gonna compare the config files now, though
1192804519 P * coderanger_ 
1192805930 J * epicbjorn bjorn@217.68.115.167
1192806157 J * dowdle ~dowdle@scott.coe.montana.edu
1192806456 J * Yvo ~yvonne@91.64.217.106
1192806484 J * JonB ~NoSuchUse@0x535f65c3.kjnxx7.adsl-dhcp.tele.dk
1192806531 P * Yvo 
1192806759 Q * JonB 
1192807465 Q * baldy_ Ping timeout: 480 seconds
1192807730 J * baldy baldy@brain.servercrew.de
1192807929 M * faheem__ Currently, I'm seeing (not as root)
1192807931 M * faheem__ /usr/sbin/vserver - build --help
1192807931 M * faheem__ vnamespace: clone(): Operation not permitted
1192807945 M * daniel_hozac as expected.
1192807951 M * faheem__ This seems a little -- unncessary. :-) I'm just asking for the help text.
1192808019 M * faheem__ unncessary -> unnecessary.
1192808088 M * daniel_hozac i don't really feel like adding special cases for use-cases that aren't very interesting...
1192808172 Q * epicbjorn Quit: Changing server
1192808931 M * micah faheem__: did you recently report this bug to debian?
1192809066 J * julius_ ~julius@p57B26F1E.dip.t-dialin.net
1192809371 Q * meandtheshell Quit: Leaving.
1192809505 Q * Julius Ping timeout: 480 seconds
1192809525 J * ntrs_ ~ntrs@79.125.252.183
1192810008 Q * lilalinux_ Remote host closed the connection
1192810058 M * faheem__ micah: The "help" thing? No, just noticed it just now.
1192810069 M * faheem__ micah: Is it Debian specific?
1192810098 M * daniel_hozac no, but it was reported on the Debian BTS yesterday...
1192810151 M * faheem__ daniel_hozac: Hmm, coincidence. :-)
1192810277 N * Bertl_zZ Bertl
1192810281 M * Bertl morning folks!
1192810314 M * dowdle Bertl: Good morning.
1192810357 M * faheem__ Bertl: Hi.
1192810368 M * dowdle Bertl: Say, this network camera is a powered device and uses an AC/DC adapter for power.  It is the USA electrical standard.  You have an adaptor so you can use it there?
1192810388 M * dowdle Bertl: Cost of shipping via US Postal Service International Express (6-10 days) is $28 so that isn't too bad.
1192810399 M * Bertl dowdle: double check that it can handle 220V
1192810421 M * dowdle Bertl: No, it is 110V US standard.
1192810431 M * faheem__ Any thoughts on a simple way to save/restore iptables rules? There appears to be no canonical way to do this. I was something simple that will work out of the box on Debian...
1192810447 M * daniel_hozac faheem__: uh, iptables-save+iptables-restore?
1192810458 M * Bertl dowdle: well, most PSUs (for such units) can handle it
1192810480 M * Bertl dowdle: what is the voltage the camera itself uses?
1192810504 M * dowdle Ok.  I'll not worry about it then.  The box is still in shrinkwrap and I'd rather keep it that way to send it to you... so I'm not going to take the power adapter out to look at it.
1192810530 Q * _gh_ Ping timeout: 480 seconds
1192810549 M * dowdle Ok, I found the User's Guide for it online so am looking.
1192810610 M * dowdle Power  - External power supply 12V AC, 9.6 VA (PS-D, included), 9-15V AC, min. 10VA, or
1192810610 M * dowdle 9-15V DC, min. 7W.
1192810669 M * Bertl should be fine
1192810693 M * dowdle Bertl: Here's the User Guide if you want to check it out ahead of time: http://www2.axis.com/files/userguide/2100/2100ug.pdf
1192810705 M * Bertl yeah, found the pages already, but tx
1192810780 M * dowdle Bertl: You mean you know how to use Google too? :)
1192810791 M * Bertl barely :)
1192810813 M * Bertl it even has Linux in the system requirements, nice :)
1192810846 M * dowdle I've used a different model at my previous job.  I wonder if their camera is still up?
1192811372 M * faheem__ daniel_hozac: I can't find any docs for iptables save/restore. Can these be run automatically at bootup or whatever?
1192811481 Q * alex_ Quit: Leaving
1192811483 M * Bertl dilinger: do you know what kernel/version is on that camera?
1192811483 M * faheem__ Sorry, see man pages.
1192811515 Q * dreamind Quit: dreamind
1192811636 M * Bertl s/dilinger/dowdle/
1192811675 M * faheem__ I'm looking for something that will restore from a file on bootup. Guess I could add a script around iptables-restore, but hate to re-invent the wheel. Oh, well, I guess this is OT here anyway.
1192811703 M * dowdle Bertl: Oh... I was wondering.
1192811712 M * dowdle I doubt the documentation or the box says version numbers.
1192811721 M * Bertl faheem__: hmm, you dirsto should have runlevel scripts called 'iptables'
1192811724 M * dowdle I don't know when it was purchased (we have a few unused ones).
1192811737 M * dowdle Bertl: I'm thinking it is a 2.2 kernel
1192811748 M * Bertl faheem__: and I would assume, they will read /etc/sysconfig/iptables
1192811757 M * dowdle And they don't have a way, to the best of my knowledge, to update it.
1192811772 M * dowdle Although if it is like the 2120's, there is a bit of free space that you can store stuff in if desired.
1192811795 M * dowdle I don't recall the CPU family but theoretically you could upload binaries.  I don't recall if it has telnet and/or ssh.
1192811819 M * Bertl no worries, I'll figure that out :)
1192811823 M * dowdle I know it does have web... but I do recall issuing standard commands from a command line on the 2120... perhaps busybox?
1192811831 M * dowdle But that was several years ago and my memory isn't so good.
1192811841 M * dowdle But you can get the prompt and uname it.
1192811945 J * tanjix ~tanjix@office.star-hosting.de
1192811948 M * tanjix hello toegether
1192811957 M * Bertl wb tanjix!
1192811963 M * tanjix hi Bertl
1192811967 M * tanjix I've a question
1192811986 M * tanjix regarding the disk i/o limiting
1192811990 M * tanjix which i found on the FAQ
1192812015 Q * ntrs_ Ping timeout: 480 seconds
1192812020 M * tanjix are you familiar a bit with that?
1192812024 M * Bertl dowdle: Linux kernel 2.0.40
1192812031 M * dowdle Bertl: But 2.2 was extremely solid and stable unlike the kernels we have today. :(
1192812043 M * dowdle Ok, 2.0 about the same as 2.2 for stability.
1192812050 M * Bertl busybox 0.51
1192812089 M * tanjix it is told to do: echo "cfq" > /sys/block/hdc/queue/scheduler - where hdc is the hard drive....
1192812098 M * tanjix i am running each guest in a lvm container...
1192812106 M * tanjix so should i do this fpr each dm-XX dvice ?
1192812118 M * Bertl tanjix: yep, would be advised
1192812127 M * dowdle Bertl: That's not in the manual... google must be good to you.  Did you find a hacking the axis network type of page?
1192812134 M * faheem__ Bertl: Etch doesn't seem to have runlevel iptables scripts. :-)
1192812137 M * Bertl tanjix: maybe put it into the init scripts
1192812144 M * tanjix Bertl: so i must create the queue folder under each dm-XX ?
1192812148 M * tanjix because this does not exist
1192812167 M * Bertl tanjix: no, it should be already there for each real device
1192812172 M * tanjix no it is not
1192812181 M * Bertl tanjix: so, for lvm, that probably means no
1192812192 M * tanjix Bertl: no for what?
1192812215 M * Bertl tanjix: as lvm2 just uses device mapper (i.e. it is not a full hardware device per se)
1192812230 M * Bertl dowdle: http://www.axis.com/techsup/cam_servers/cam_2100/firmware.php
1192812246 M * Bertl dowdle: interestingly, they provide a lot of information
1192812246 M * tanjix Bertl: so i cannot use the i/o limit there?
1192812267 M * Bertl tanjix: you can, just put it on the underlying devices (the real ones)
1192812280 M * tanjix so to "sdb"?
1192812289 M * dowdle Bertl: Yikes, that throws me to a login page... but thanks for trying.
1192812294 M * faheem__ Looks like it was removed in sarge...
1192812473 M * Bertl dowdle: MIPS CPU
1192812592 M * Bertl faheem__: interesting, maybe got replaced by something 'better'?
1192812603 J * JonB ~NoSuchUse@0x5739c8b4.roennqu1.broadband.tele.dk
1192812609 M * Bertl faheem__: or maybe was moved into a separate (non default) package?
1192812648 M * dilinger Bertl: ping
1192812656 M * Bertl dilinger: pong!
1192812669 M * dilinger Bertl: did you see that we're still seeing the jffs2 bug w/ the new vserver patch?
1192812682 M * faheem__ Bertl: No, I think the maintainer decided he didn't want to maintain it, or didn't approve on a iptables init script, or something. :-) I recall reading something about it in an old README.Debian (since removed, it looks like).
1192812692 M * Bertl dilinger: nope? details on olpc?
1192812698 M * faheem__ Pity, I think an iptables init script is a really good idea, and the way to go.
1192812723 M * faheem__ "on a" -> "of an"
1192812768 M * Bertl dilinger: so most likely the CoW link breaking is not the cause, just the trigger then ...
1192812775 M * faheem__ There is some discussion at http://www.debian-administration.org/articles/445. Since this is clearly OT, I'll shut up now. :-)
1192812785 M * dilinger Bertl: https://dev.laptop.org/ticket/4184
1192812789 M * dilinger down at the bottom
1192812791 M * Bertl dilinger: but we should have the debug stuff in place now, to investigate
1192812800 M * dilinger Bertl: btw, if you're not getting emails from trac, let me know..
1192812824 M * Bertl I'm not sure, at least they do not end up in my main box
1192812836 M * Bertl dilinger: will check shortly, maybe the headers are funny
1192813011 M * Bertl dilinger: could you upload the log somewhere so that we see all the special chars?
1192813111 M * dilinger Bertl: i don't have log anymore, that was from almost a full 24 hrs ago
1192813128 M * dilinger i've worked on various other bugs since then
1192813130 J * babyfish ~806b69fe@207.250.49.24
1192813132 M * Bertl dilinger: this is indeed interesting ... if I interpret it correctly, the vfs already contains the zero
1192813157 M * Bertl dilinger: in your trace, the line with 87.682516
1192813165 J * jmcaricand ~user@d83-179-172-170.cust.tele2.fr
1192813206 M * Bertl that one shows the the lookup of /root/t/zc returns with a dentry name of \0zc
1192813228 M * Bertl checking now if I messed up something in the lookup code
1192813346 M * Bertl dilinger: nope, not getting trac messages, as it seems
1192813361 M * Bertl dilinger: last one I got was the test message from Ivan
1192813361 M * dilinger grr
1192813376 Q * ftx Read error: Connection reset by peer
1192813385 M * Bertl Re: #1 BLOC -: There isn't a laptop in the hands of every child
1192813434 M * dilinger see if you got that one..
1192813453 M * Bertl yep
1192813464 M * dilinger ok
1192813473 M * babyfish Hey guys!
1192813474 M * dilinger #$!$.  someone put Bertl rather than bertl
1192813486 M * JonB babyfish: hey Nemo
1192813492 M * babyfish :)
1192813499 M * Bertl dilinger: ah, cool, better make that an alias :)
1192813505 M * babyfish A quick question about vserver config directory
1192813520 M * Bertl hey babyfish! go ahead ...
1192813546 M * babyfish I see there's a file called "environment", but it doesn't appear to be used in the scripts anywhere...
1192813568 M * Bertl babyfish: what util-vserver version?
1192813592 M * babyfish Heh - let me check here :) Which version should this be in?
1192813606 Q * JonB Quit: This computer has gone to sleep
1192813622 M * Bertl babyfish: we are at 0.30.214, that probably uses it
1192813647 M * babyfish I think I may be looking at 0.30.214 source code
1192813683 M * babyfish Oh ok - thanks, let me look for 214
1192813725 M * babyfish have a great day guys!
1192813735 J * hparker ~hparker@linux.homershut.net
1192813745 M * Bertl babyfish: you're welcome! feel free to hang around
1192813778 M * Bertl dilinger: do we have somebody really good at the vfs layer?
1192813861 M * dilinger Bertl: nope
1192813895 J * _gh_ ~gerrit@bi01p1.co.us.ibm.com
1192813908 Q * babyfish Quit: CGI:IRC 0.5.9 (2006/06/06)
1192813952 M * Bertl dilinger: okay, is the bug reproduceable with some script? maybe even in qemu?
1192814064 M * dilinger Bertl: yes, the script in that bug report
1192814067 J * coderanger_ ~coderange@marvin-27.dynamic2.rpi.edu
1192814097 M * dilinger Bertl: the one mitch posted there
1192814122 M * dilinger i have no idea whether it's reproducible in qemu.  do you have an XO?
1192814170 M * Bertl dilinger: yes, but it is easer to do updates in qemu
1192814204 M * dilinger Bertl: ok, well i have no idea.  i haven't used qemu in a long time
1192814219 M * Bertl dilinger: np, where is the script linked?
1192814229 P * coderanger_ 
1192814253 M * Bertl dilinger: ah, it is a variation of my own script
1192814271 M * Bertl fine, so that might suffice then ...
1192815096 J * sharkjaw ~gab@216-161-9.0503.adsl.tele2.no
1192815947 Q * ema Quit: leaving
1192815996 J * Linus ~Lucifer@bl7-134-112.dsl.telepac.pt
1192816266 M * Bertl wb sharkjaw! Linus!
1192816352 Q * julius_ Ping timeout: 480 seconds
1192816581 J * JonB ~NoSuchUse@0x5739c8b4.roennqu1.broadband.tele.dk
1192816965 M * bXi finally got some decent coding gear
1192816994 M * JonB like what?
1192817040 M * bXi logitech g15
1192817045 M * bXi hellofa lot better then my old keyboard
1192817054 J * dna ~dna@64-215-dsl.kielnet.net
1192817071 M * bXi my { and } keys were stuck and everything
1192817073 Q * JonB Quit: This computer has gone to sleep
1192817123 M * dowdle Bertl: How'z your todo list coming?
1192817197 M * Bertl it is getting longer currently :/
1192817209 M * dowdle Bertl: That isn't going to change I'm sure.
1192817248 M * dowdle Bertl: Ok, it is race.  Which will arrive first?  Answers to questions or a package from the states.  I haven't mailed it yet though.
1192817267 M * dowdle Estimated arrival after mailed, 6-10 days.
1192817332 M * Bertl okay, I guess I can beat that :)
1192817577 M * Mitch_Bradley Bertl: If there is anything I can do to help with the COW race, I'm available.
1192817583 Q * Linus Remote host closed the connection
1192817602 M * Bertl Mitch_Bradley: okay, I have a new theory and would like to discuss it .. 
1192817627 M * Bertl Mitch_Bradley: you had a look at the 'new' debug output?
1192817632 A * Mitch_Bradley brings up the source for reference
1192817665 M * Mitch_Bradley Bertl: I don't have a kernel with that code, but I have seen logs from you
1192817692 M * Mitch_Bradley I could get a kernel from dilinger...
1192817703 Q * sharkjaw Remote host closed the connection
1192817752 M * Bertl Mitch_Bradley: you have the source, that should be fine, for the log: https://dev.laptop.org/ticket/4184
1192817787 M * Bertl Mitch_Bradley: that is with the recent patch to prevent any CoW race in the affected area
1192817804 M * Bertl Mitch_Bradley: I'm looking at the line with timestamp 87.682516
1192817839 M * Mitch_Bradley ok, i see that line
1192817868 M * Mitch_Bradley looks like "zc" turned into <space>zc
1192817907 M * Bertl now, till now I assumed that we have some weird characters prepended in the dentry, but, spending some more thought on it, %*s will probably prepend the space, if * says 3 but the name is actually 2 char + \0 no?
1192817948 M * Bertl (still have to verify that)
1192818023 M * Mitch_Bradley yes, that is probably correct.
1192818039 M * Mitch_Bradley in fact, I'm sure that's how printf works.
1192818071 M * Bertl which means, that, if I'm right here, the dentry has the correct name, but the wrong length
1192818102 M * Mitch_Bradley so, with that understanding, the debug output is consistent with the observed result at the vfs interface
1192818107 M * Bertl note, that the line with the stamp 87.682516 does not modify anything before printing
1192818133 M * Bertl i.e. we do a path_lookup(pathname, LOOKUP_FOLLOW, &old_nd);
1192818155 M * Bertl (with the provided and zero terminated pathname)
1192818170 M * Bertl then we get the dentry as old_nd.dentry
1192818184 M * Bertl and create the full path like this:
1192818191 M * Bertl to = d_path(old_dentry, old_mnt, path, PATH_MAX-2);
1192818207 M * Bertl after that, we do pathlen = strlen(to);
1192818228 M * Bertl and the printk we are looking at
1192818265 M * Bertl so, whatever happened thus far, the lookup seems to provide a somewhat 'strange' dentry in some cases
1192818284 M * Mitch_Bradley but the pointer "to" is not the destination of the rename, but rather the source.
1192818310 M * Bertl yes, it will be slightly modified after that printk
1192818336 M * Bertl it is the destination of the 'copy' (i.e. splice) operation
1192818346 M * Mitch_Bradley "to" is the name with the \251 appended, then that copy gets renamed back to the original name.
1192818348 M * Bertl and consequently the source of the rename
1192818361 M * Bertl yes, precisely, steps are:
1192818364 M * Mitch_Bradley So it is the original name that is bad at some point.
1192818384 M * Bertl yes, and the line 87.682516 is the very beginning!
1192818406 M * Bertl that's the funny part .. till now, I assumed we would mess up the dentry somehow
1192818431 M * Bertl but it looks like that the vfs is actually reporting that funny dentry to us
1192818440 M * Bertl -that
1192818461 M * Mitch_Bradley Bertl: it is possible that the dentry was messed up - here's how
1192818504 M * Mitch_Bradley assume that dentries are cached.  The first path_lookup() creates a dentry and puts it in a list.
1192818550 M * Mitch_Bradley somewhere during the process of doing the first COW, that dentry gets modified by changing the length, leaving the string data intact.
1192818563 M * Mitch_Bradley The new length thus includes the null.
1192818623 M * Mitch_Bradley the second path_lookup() then matches the cached-but-modified old dentry, because it uses strcmp() instead of looking at the stored length in the dentry for the comparison.
1192818633 M * Bertl yes, but the problem is, we do not really modify any dentry
1192818634 M * Mitch_Bradley or maybe it compares the hash
1192818661 M * daniel_hozac any lookup uses both the length and the name.
1192818669 M * Bertl maybe we need to explicitely invalidate a dentry somewhere
1192818680 M * daniel_hozac shouldn't vfs_rename do that for us?
1192818695 M * Bertl it is not used directly anywhere
1192818704 M * Bertl and the do_rename() wrapper does a lot more
1192818726 M * Mitch_Bradley what if vfs_rename invalidates the dentry but the second process is already holding a reference to it?
1192818786 M * daniel_hozac yeah, that's what i've been thinking all along.
1192818796 M * Bertl I think that would be possible, we could extend the mutex over the lookup
1192818819 M * Bertl but I would rather try to detect this case and fail gracefully
1192818844 M * Bertl i.e. find some way to tell if the dentry is fine or not
1192818881 M * Mitch_Bradley I think that the retry logic will get very hairy in the "detect and fail" case.
1192818894 M * daniel_hozac we're holding the lock there.
1192818906 M * Bertl nah, not really, we would do a cleanup and return the error
1192819046 M * Bertl maybe check with d_unhashed()?
1192819054 M * daniel_hozac heh, i was just about to say that.
1192819082 M * daniel_hozac question is, will that be true? do we have enough information about the dentry to know that?
1192819087 M * Bertl the thing is, we should probably take dcache locks for that
1192819103 M * daniel_hozac nah, d_unhashed is safe.
1192819114 M * Mitch_Bradley Another possibility would be to get a dentry that cannot be cached/reused.
1192819131 M * Bertl Mitch_Bradley: do you know how to do that?
1192819151 M * Mitch_Bradley I don't know.  I'm just making up stuff on the fly.
1192819162 M * Mitch_Bradley but that sounds like it would good if it were possible.
1192819168 M * Bertl hehe, okay
1192819216 M * Mitch_Bradley Perhaps you could take a lock before the lookup, then copy the dentry to a private copy, then release/invalidate the real one, then release the lock.
1192819223 M * Bertl the following options look interesting to me:
1192819231 M * Bertl #define LOOKUP_NOALT            32
1192819237 M * Bertl - locked when lookup done with dcache_lock held
1192819244 M * Bertl #define LOOKUP_REVAL            64
1192819251 M * Bertl - dentry cache is untrusted; force a real lookup
1192819262 M * Mitch_Bradley bingo!
1192819303 M * Bertl yeah, the only problem is, we cannot keep the dcache_lock
1192819359 M * daniel_hozac hmm, i thought LOOKUP_NOALT was to avoid looking the alternative root?
1192819360 M * Bertl so we have two options here, re-lookup right before the rename, but we have to drop the lock before that anyway, I guess
1192819361 M * daniel_hozac +in
1192819405 M * Bertl daniel_hozac: hmm, I was just copying from the comment
1192819418 M * Bertl which might be completely wrong and misleading, of course :)
1192819428 M * daniel_hozac hehe, okay
1192819453 M * daniel_hozac well, i think d_unhashed once we've grabbed the cow mutex should be fine...
1192819467 M * daniel_hozac provided that the dentry actually _is_ unhashed.
1192819483 M * Bertl sure, the REVAL shouldn't hurt either
1192819506 M * faheem__ To use the clone method, does the vserver have to be running or not? Does the corres volume even need to be mounted?
1192819507 M * daniel_hozac i don't think REVAL would help though.
1192819513 M * Bertl but I think we should verify a few of those theories first
1192819530 M * Bertl like where the \0 actually is (I'm going to do that now)
1192819542 M * Bertl and whether the dentry is unhashed or not 
1192819545 M * daniel_hozac faheem__: it's best if it's not running.
1192819552 M * daniel_hozac faheem__: what volume are you talking about?
1192819592 M * Bertl Mitch_Bradley: would you like to do some testing too, I have a few things in mind to test which are related but do not require great changes or new kernels
1192819608 J * JonB ~NoSuchUse@0x5739c8b4.roennqu1.broadband.tele.dk
1192819622 Q * tanjix Ping timeout: 480 seconds
1192819653 M * Mitch_Bradley sure
1192819680 M * Bertl I was wondering what massive parallel 'mv's could trigger on jffs2
1192819696 M * Bertl as the current issues does not affect ext2/3 at all
1192819702 M * faheem__ daniel_hozac: lvm volume.
1192819723 M * faheem__ daniel_hozac: Does it need to be mounted?
1192819723 M * daniel_hozac faheem__: well, if you want either the source or destination to be on LVM, yes, it has to be mounted...
1192819734 M * daniel_hozac it's not psychic, after all.
1192819743 M * Bertl Mitch_Bradley: e.g. trying to execute 'mv a b' and 'mv b a' at once, like 1000 times in parallel or so?
1192819744 M * faheem__ daniel_hozac: Ok, thanks. Yes, fair enough. :-)
1192819779 M * Mitch_Bradley Bertl: would I need to give a and b any special attributes?
1192819798 M * Bertl no, just plain old files with minimal content
1192819849 Q * JonB 
1192819854 M * faheem__ I'm currently getting errors like
1192819856 M * faheem__ umount: /tmp: must be superuser to umount
1192819856 M * faheem__ failed.
1192819856 M * faheem__ Deactivating swap...Not superuser.
1192819856 M * faheem__ failed.
1192819871 M * daniel_hozac your guest is trying to do things it's not allowed to do.
1192819875 M * faheem__ When trying to stop a vserver. Don't recall seeing this ealier.
1192819881 M * Bertl result of older tools used for installation
1192819892 M * faheem__ Bertl: ??
1192819894 M * daniel_hozac or a distribution without an initpost script.
1192819909 M * Bertl I assumed debian/debian here :)
1192819948 M * daniel_hozac yeah, but only etch, lenny and sid are supported right now.
1192819957 M * faheem__ Bertl: I just created it using 0.30.214-3~bpo.1 (in etch).
1192820071 M * Mitch_Bradley Bertl: do you want a and b to be the same filenames for all 1000 runs?  Because if so, a lot of the operations will fail because the source file doesn't happen to exist at the time.
1192820079 M * faheem__ Should I nuke all vserver related stuff and start from scratch, or what?
1192820101 M * Bertl Mitch_Bradley: that's the idea, so we get some racy bouncing between a and b
1192820113 M * Bertl faheem__: nah, that one is harmless
1192820138 M * Bertl faheem__: you can even ignore it, no problem, but I wonder how that happens with 0.30.214
1192820152 M * daniel_hozac indeed, that is peculiar.
1192820192 M * faheem__ Bertl: The error is harmless? Ok, but would prefer not to see it. Wasn't seeing it with earlier versions... Debian bug time?
1192820218 M * Bertl faheem__: maybe, I guess daniel_hozac will look into it
1192820220 M * daniel_hozac faheem__: try rerunning the initpost script.
1192820235 M * faheem__ daniel_hozac: how do I do that?
1192820255 M * daniel_hozac faheem__: i.e. /usr/lib*/util-vserver/distributions/debian/initpost /etc/vservers/<guest> /usr/lib*/util-vserver/util-vserver-vars
1192820285 M * faheem__ Yowza! :-) Ok.
1192820368 M * daniel_hozac hmm, but for that, you actually want to export MIRROR=<your favorite Debian mirror>.
1192820455 M * Mitch_Bradley Bertl: the net result is a single file named a, containing the data that was originally in a.
1192820471 M * faheem__ daniel_hozac: Ok, ran it. Now what?
1192820481 M * Mitch_Bradley Bertl: I tried it twice, same result both times.  So nothing unexpected.
1192820487 M * daniel_hozac faheem__: do you still see those messages when stopping it?
1192820496 M * Bertl Mitch_Bradley: okay, another one:
1192820508 M * faheem__ daniel_hozac: Ah. No, I don't.
1192820530 M * daniel_hozac faheem__: so what command did you use to build it? 
1192820540 M * daniel_hozac faheem__: have you upgraded it since?
1192820541 M * Bertl Mitch_Bradley: 'cp a bN && mv bN a' in parallel with different N
1192820612 M * faheem__ vserver etch_template build -m debootstrap --hostname etch_template.duke.earth --rootdir /vservers/etch_template/ --interface eth0:192.168.1.201/24 -- -d etch -m http://debian.csail.mit.edu/debian/ -- --resolve-deps
1192820631 M * faheem__ No, just created a user, changed root password, added a few packages.
1192820651 M * faheem__ Sorry, yes, I think I ran apt-get upgrade.
1192820685 M * daniel_hozac faheem__: just curious, does ls -ld /usr/lib*/util-vserver/distributions/{etch,sid,lenny} show a bunch of symlinks to debian on your host?
1192820730 M * faheem__ Actually, I used /usr/lib64. Does it make any difference?
1192820786 M * faheem__ Lenny and sid do, yes.
1192820814 M * faheem__ util-vserver seems to be under both lib and lib64.
1192820828 M * Bertl hmm
1192820846 M * Bertl maybe you installed i586 and amd64 packages?
1192820862 M * daniel_hozac etch doesn't?
1192820869 M * daniel_hozac that explains it then.
1192820887 M * faheem__ Bertl: If you are talking to me, then no, just amd64. dpkg won't tolerate such shennanigans.
1192820908 M * faheem__ daniel_hozac: No, no link from etch.
1192820931 M * daniel_hozac do you have an etch there, at all?
1192820935 M * Mitch_Bradley Bertl: that last test worked too.  Net result is "a" with the right contents.  I made pretty large - over a megabyte - to get some concurrency going.
1192820972 M * Bertl Mitch_Bradley: actually make it like 5 chars or so, we are not interested in the copy concurrency
1192820988 M * Bertl we are interested in the mv (aka. rename)
1192820992 M * faheem__ daniel_hozac: Yes, there is an etch. Hmm. Appears to be empty, though. Is this a bug?
1192821003 M * faheem__ /usr/lib64/util-vserver/distributions/etch
1192821008 M * faheem__ is empty.
1192821011 M * daniel_hozac faheem__: a directory?
1192821066 M * faheem__ daniel_hozac: Yes, empty directory.
1192821102 M * daniel_hozac i guess nobody was happy with that directory -> symlink conversion.... :)
1192821103 J * JonB ~NoSuchUse@0x5739c8b4.roennqu1.broadband.tele.dk
1192821118 M * faheem__ daniel_hozac: ?
1192821134 M * faheem__ So, should I report this, or what?
1192821148 M * daniel_hozac i guess so...
1192821163 M * daniel_hozac micah: ping?
1192821172 M * faheem__ daniel_hozac: Debian BTS? What should I tell them, add a symlink?
1192821202 M * daniel_hozac the symlink should already be in the package.
1192821227 M * faheem__ daniel_hozac: So, why is it not there?
1192821245 M * daniel_hozac i'm guessing dpkg has a problem similar to rpm in that it won't replace a directory with a symlink or a file on an upgrade.
1192821250 A * micah reads backlog to catch up
1192821286 M * faheem__ daniel_hozac: Ah, dpkg upgrade problem? Was a directory, now needs to be a symlink?
1192821297 M * daniel_hozac IMHO, yes.
1192821308 M * faheem__ daniel_hozac: Workaround, purge/reinstall?
1192821315 M * daniel_hozac require further investigation though...
1192821330 M * daniel_hozac reinstall should be fine, or you could just do it manually.
1192821342 M * faheem__ daniel_hozac: Ok, will file with Debian BTS. Thanks.
1192821354 M * daniel_hozac well, micah is already reading this, so i guess that's not needed ;)
1192821437 M * Mitch_Bradley Bertl: I got a few instances of "cp: skipping file `a', as it was replaced while being copied", otherwise it worked fine in a run of 1000
1192821449 M * Mitch_Bradley The final result was correct
1192821473 M * micah I dont understand the problem here
1192821505 M * daniel_hozac micah: /usr/lib*/util-vserver/distributions/etch should be a symlink to debian. for some reason, it's not.
1192821515 M * micah in my .214 install of util-vserver I have a symlink /usr/lib/util-vserver-distributions/etch which points to the debian directory which has contents
1192821529 M * daniel_hozac was that upgraded from e.g. 0.30.212?
1192821530 M * micah daniel_hozac: what I dont understand here is why mine is, but faheem__'s is not
1192821541 M * daniel_hozac i'm thinking this is only a problem on upgrades.
1192821545 M * Bertl Mitch_Bradley, daniel_hozac:
1192821549 M * micah mmm, I believe it was... let me test that
1192821549 M * Bertl vxdprintk(VXD_CBIT(misc, 1), "cow test »%*s« »%-*s« »%.*s«", 3, "ab\0", 3, "ab\0", 3, "ab\0");
1192821557 M * Bertl [   79.320305] vxD: 83d43530: cow test » ab« »ab « »ab«
1192821586 A * micah goes to upgrade a 0.30.212 util-vserver to the backported one
1192821586 J * Julius ~julius@p57B26F1E.dip.t-dialin.net
1192821596 Q * bragon_ Ping timeout: 480 seconds
1192821640 M * daniel_hozac Bertl: the third should be correct, IMHO.
1192821661 M * daniel_hozac it should've outputted the NULL byte, it's just not visible.
1192821676 J * zLinux ~zLinux@88.213.26.14
1192821713 M * Bertl daniel_hozac: maybe we should patch vprintk() to output \0 too?
1192821717 Q * JonB Quit: This computer has gone to sleep
1192821729 M * daniel_hozac you mean it doesn't?
1192821755 M * Bertl nah, I meant in a easy readable/detectable way
1192821760 M * Bertl *an
1192821763 M * faheem__ micah: File with BTS or not?
1192821766 M * daniel_hozac ah, yeah, that makes sense.
1192821772 M * micah faheem__: i'm doing some tests
1192821791 M * micah just one moment
1192821796 M * faheem__ micah: Is that a no ? :-) Can file if desired.
1192821810 M * micah faheem__: thats a "please hold"
1192821867 M * Bertl [  193.552831] 813380b0: 81273310[»zc«:3:16] 7a 63 00 00
1192821898 M * daniel_hozac 16 is the flags?
1192821900 M * Bertl current, de, name, len, unhashed  4xbytes
1192821921 J * Linus ~Lucifer@bl7-134-112.dsl.telepac.pt
1192821940 Q * hparker Quit: peer reset by connection
1192821963 M * daniel_hozac so once we grab the cow mutex, if (d_unhashed(old_dentry)) should make us safe, right?
1192821982 M * Bertl let me upload the log with the mutex removed
1192822022 Q * Linus 
1192822023 M * Bertl http://paste.linux-vserver.org/7033
1192822052 M * Bertl the \0 is actually outputed correctly here
1192822052 M * micah faheem__: if I upgrade from 0.30.212-1 to 0.30.214-3~bpo.1 my /usr/lib/util-vserver/distributions/debian directory is *not* empty
1192822062 M * micah root@24b6:~# ls  -l /usr/lib/util-vserver/distributions/debian/
1192822062 M * micah total 12
1192822062 M * micah -rw-r--r-- 1 root root 5833 2007-09-26 07:53 debootstrap.script
1192822062 M * micah -rwxr-xr-x 1 root root 3529 2007-09-26 07:53 initpost
1192822080 M * daniel_hozac micah: it's the etch directory that's empty.
1192822080 M * faheem__ micah: I think I may have gone through 213.
1192822087 M * micah ah, etch
1192822091 M * faheem__ Yes, the etch directory.
1192822096 M * daniel_hozac micah: rather than the symlink it should be.
1192822099 M * micah root@24b6:~# ls  -ld /usr/lib/util-vserver/distributions/etch   
1192822099 M * micah lrwxrwxrwx 1 root root 6 2007-10-19 12:26 /usr/lib/util-vserver/distributions/etch -> debian
1192822103 M * micah looks right
1192822111 M * daniel_hozac indeed it does...
1192822118 M * faheem__ micah: Let me check dpkg logs.
1192822150 J * tanjix ~tanjix@dslb-084-058-027-230.pools.arcor-ip.net
1192822210 M * faheem__ micah: Yes, util-vserver 0.30.212-1 -> util-vserver 0.30.213-1~bpo.1 -> util-vserver 0.30.214-3~bpo.1
1192822248 M * Bertl http://paste.linux-vserver.org/7034 (proper non UTF8 copy)
1192822258 M * micah faheem__: ok, that may have caused it, i'll attempt this
1192822304 J * Linus ~Lucifer@bl7-134-112.dsl.telepac.pt
1192822315 M * dilinger Bertl, Mitch_Bradley: if you guys need me to attempt to make sense of vfs code, lemme know.. otherwise i'm going to assume you both have a handle on this
1192822381 M * Bertl dilinger: any help is appreciated, we are looking for a way to 'protect' a dentry
1192822432 M * Bertl the minimum we need to do is to ensure that the dentry is valid over the vfs_rename
1192822436 M * daniel_hozac Bertl: http://people.linux-vserver.org/~dhozac/p/k/delta-cow-fix17.diff
1192822442 M * daniel_hozac i think this is sufficient.
1192822467 M * daniel_hozac at least for the COW-case. racing with rename is still possible.
1192822505 M * Bertl yes, and I think we should not focus on the CoW vs CoW race here
1192822517 M * micah faheem__: amazing, there is no i386 package of util-vserver .213 at backports
1192822524 M * Bertl daniel_hozac: although I'm pretty sure it would hide the issue perfectly
1192822563 M * Bertl it should be possible to get a locked dentry ... searching now
1192822630 M * daniel_hozac Bertl: doing the same thing before vfs_rename should be safe then, no?
1192822633 M * faheem__ micah: I should probably mention that I'm doing all this  on amd64, and I build the 214 package myself from the provided backport sources. :-)
1192822659 M * micah faheem__: yes, I knew that
1192822660 M * Bertl daniel_hozac: haha! we just have to use dget_locked()
1192822668 M * faheem__ micah: You could build 213 from source?
1192822681 Q * yarihm Quit: Leaving
1192822684 M * micah faheem__: I have it myself, since I originally built it, but I am surprised backports doesn't
1192822694 M * faheem__ Oh, Ok.
1192822738 M * Bertl daniel_hozac: so, I propose to do a dget_locked() under dcache_lock, then check (at the beginning) and keep the dentry locked till compeltion
1192822763 M * faheem__ I still see it on etch-backports, at least in amd64.
1192822764 Q * Linus Quit: I'll Be back
1192822767 M * Bertl daniel_hozac: not sure that will work, but I'm going to try shortly
1192822796 M * faheem__ Anyway, just shoot me an email at faheem@email.unc.edu if you want me to file a bug or want further info. Sorry about the bother.
1192822848 M * micah faheem__: yeah, there is no i386 in backports
1192822865 M * faheem__ micah: Shall I nuke 214 and reinstall? Or leave alone for the moment in case you want more debugging info?
1192822872 M * daniel_hozac Bertl: hmm. can't we use dentry->d_lock?
1192822887 M * micah faheem__: please continue to hold :)
1192822943 J * Linus ~Lucifer@bl7-134-112.dsl.telepac.pt
1192823014 J * tanjix2 ~tanjix@office.star-hosting.de
1192823090 M * daniel_hozac Bertl: dget_locked seems to have an entirely different purpose.
1192823158 Q * tanjix Ping timeout: 480 seconds
1192823161 M * Bertl daniel_hozac: please elaborate
1192823202 M * daniel_hozac the comment in include/linux/dcache.h seems to say dget_locked is for cases when the dentry has no references.
1192823208 M * micah faheem__: ok, I believe the problem was the upgrade path from .213 to .214, as daniel_hozac has suggested /usr/lib/util-vserver/distributions/etch is empty but /usr/lib/util-vserver/distributions/debian is not
1192823239 M * daniel_hozac Bertl: i.e. it doesn't actually lock anything or so.
1192823272 M * Bertl hmm
1192823273 M * daniel_hozac Bertl: but i think locking dentry->d_lock would achieve what you want, no?
1192823293 M * Bertl no, we can't possibly hold a lock over splice/rename
1192823377 M * faheem__ micah: Were you able to reproduce then? If so, do you feel any action is warranted? Just curious?
1192823383 M * Bertl hmm, although for the rename it should be fine
1192823400 M * micah faheem__: i was able to reproduce it
1192823401 M * daniel_hozac Bertl: forgive my ignorance, but why is that?
1192823411 M * micah faheem__: and yes, it should be fixed
1192823418 M * Bertl daniel_hozac: anything sleeping will blow up?
1192823441 M * daniel_hozac :q
1192823449 M * micah :wq
1192823454 M * daniel_hozac wrong workspace, heh.
1192823468 M * daniel_hozac Bertl: duh, of course. sorry.
1192823479 M * micah faheem__: would you mind filing a bug about this issue? then I will be sure to fix it in the next upload once I have enough time to focus on it
1192823674 M * micah faheem__: if you cannot, I will do so
1192823703 J * DavidS ~david@vpn.uni-ak.ac.at
1192823712 M * faheem__ micah: Sure, no problem.
1192823740 M * micah thanks I appreciate it
1192823741 M * faheem__ Can reportbug output a file. The server in question doesn't have outgoing email.
1192823756 M * faheem__ I guess I'll look at the manual.
1192823784 M * micah when you compose the report, its in an editor, so you can just save that somewhere
1192823806 M * micah also -o works
1192823829 M * Bertl daniel_hozac: I think we can do the do_rename() style of locking _after_ the lookup_create(new)
1192823854 N * Supaplex_ Supaplex
1192823872 M * Bertl daniel_hozac: and if we verify that the old dentry is still cached/valid inside the locking, we should be fine for the rest
1192823897 M * daniel_hozac ah, yeah, good idea.
1192824133 J * mjt ~mjt@nat.corpit.ru
1192824167 J * bonbons ~bonbons@2001:5c0:85e2:0:20b:5dff:fec7:6b33
1192824670 M * Bertl wb mjt! bonbons!
1192825063 M * faheem__ micah: Ok, submitted.
1192825085 M * faheem__ Bertl: Do you have a bot running, or something? :-)
1192825139 M * DavidS faheem__: it is the bertl_bot!
1192825146 M * faheem__ You're very quick with the welcome messages.
1192825148 M * daniel_hozac Bertl: time to test that new trick ;)
1192825154 M * Bertl faheem__: are you sure you aren't a bot too?
1192825171 J * fatgoose_ ~samuel@76-10-151-220.dsl.teksavvy.com
1192825172 M * daniel_hozac hehe
1192825174 M * faheem__ Bertl: Pretty sure. (Pinches self). No, flesh and blood.
1192825185 M * Bertl faheem__: any proof of that?
1192825185 M * fatgoose_ hola
1192825206 M * faheem__ Bertl: What did you have in mind? :-)
1192825219 M * Bertl faheem__: I don't know, you tell me?
1192825234 M * faheem__ Bertl: We could do the Turing test...
1192825289 M * Bertl good idea, let's do the extra credit task too :)
1192825291 M * DavidS http://xkcd.com/329/ <<-- turing test extras
1192825342 M * faheem__ DavidS: Good one. :-)
1192825372 M * Bertl faheem__: that is what daniel_hozac was referring to :)
1192825373 M * DavidS yeah, xkcd rulez
1192825394 M * Bertl faheem__: we had a discussion about it yesterday, if you like to read up on the logs ...
1192825435 M * faheem__ Bertl: Hmm, really?
1192825461 M * faheem__ I guess I should hang around here more often.
1192825469 M * Bertl definitely!
1192825762 M * faheem__ micah: Can I go ahead and nuke the misbehaving 214 now? The report went through.
1192825781 M * micah faheem__: sure
1192825832 J * Aiken ~james@ppp121-45-206-11.lns1.bne1.internode.on.net
1192825841 M * Bertl hey Aiken!
1192825861 M * Aiken hello
1192825869 M * Bertl how's going?
1192825880 M * Aiken good
1192825950 M * Aiken still have to do my upgrades, happy with my gentoo guest under 2.4.32-vs1.2.10
1192826281 M * Aiken is there a patch for 2.6.23?
1192826304 M * Aiken I think I recently saw someone say they were working on it, wondering how that is going
1192826306 M * daniel_hozac nothing stable or fully-featured.
1192826309 Q * nou Ping timeout: 480 seconds
1192826317 M * Aiken ok
1192826325 M * Bertl Aiken: no time yet to fix it up completely
1192826458 J * nou Chaton@causse.larzac.fr.eu.org
1192826493 M * Bertl welcome nou!
1192827007 J * ntrs_ ~ntrs@79.125.248.194
1192827123 Q * Fire_Egl Ping timeout: 480 seconds
1192827329 M * faheem__ vserver - build --help says clone ... -- [-d <distribution>] --source <source>
1192827341 M * faheem__ Why is dist needed? Isn't it redundant?
1192827373 M * faheem__ Not sure what clone does...
1192827504 M * daniel_hozac it's not needed, that's why it's in []s.
1192827957 M * Bertl I think I have something unintrusive which passes all my tests
1192827968 M * Bertl let me clean it up and we'll review it
1192828153 Q * dna Quit: Verlassend
1192828597 Q * DavidS Quit: Leaving.
1192828824 Q * Piet Quit: Piet
1192828860 M * faheem__ Um, what is wrong with this? vserver etch_clone build -m clone --hostname etch_clone.duke.earth --rootdir /vservers/etch_clone --interface eth0:192.168.1.202/24 -- -m http://debian.csail.mit.edu/debian/ -- --resolve-deps --source /vservers/etch-template
1192828881 M * faheem__ invalid option -- m
1192828913 J * julius_ ~julius@p57B26F1E.dip.t-dialin.net
1192828956 M * daniel_hozac clone doesn't support specifying a mirror.
1192828965 Q * Julius Ping timeout: 480 seconds
1192828966 M * daniel_hozac since it doesn't download anything.
1192828968 M * faheem__ daniel_hozac: Oh, right.
1192829206 M * faheem__ Ok, cloned, but the clone won't start.
1192829214 M * faheem__ !paste
1192829220 M * faheem__ `paste
1192829327 M * faheem__ Um, remind me where I should paste. Just 5 lines or so.
1192829342 M * daniel_hozac paste.linux-vserver.org
1192829440 M * faheem__ http://paste.linux-vserver.org/7054. Doesn't pop up here automatically, apparently.
1192829476 M * faheem__ Hang on. May be my error. Sec.
1192829573 M * faheem__ No, don't see anything wrong here.
1192829608 M * daniel_hozac ls -l /vservers/etch_clone
1192829624 M * daniel_hozac seems like your clone is incomplete at best.
1192829668 M * faheem__ http://paste.linux-vserver.org/7055
1192829695 M * daniel_hozac which is obviously incorrect :)
1192829699 J * yarihm ~yarihm@84-75-130-73.dclient.hispeed.ch
1192829732 M * faheem__ Yikes, so I see.
1192829740 M * faheem__ Sorry, all. I'm a dodo.
1192829933 M * faheem__ I'm using 
1192829952 M * faheem__ vserver etch_clone build -m clone --hostname etch_clone.duke.earth --rootdir /vservers/etch_clone --interface eth0:192.168.1.202/24 --  --source /vservers/etch_template
1192829962 M * daniel_hozac why are you setting --rootdir?
1192829993 M * faheem__ daniel_hozac: 'Cos that's where the clone goes?
1192830016 M * daniel_hozac --rootdir is used to specify the parent directory of the guest.
1192830021 M * faheem__ daniel_hozac: I have to give a destination, surely
1192830024 M * daniel_hozac no.
1192830033 M * daniel_hozac do you have to give -m debootstrap a destination?
1192830049 M * daniel_hozac -m yum? or any other build method?
1192830051 M * Bertl the --rootdir comes from newvserver :)
1192830071 M * faheem__ daniel_hozac: So, where would the clone go, if I don't tell it?
1192830092 M * faheem__ Current directory, or something?
1192830099 M * daniel_hozac to your default guest directory/<guest>
1192830133 M * daniel_hozac just as it always does...
1192830151 M * Bertl daniel_hozac, Mitch_Bradley: http://vserver.13thfloor.at/Experimental/CoW_changes.diff
1192830179 M * Bertl I decided to upload this diff against the mainline kernel, so that the entire cow functions are shown
1192830186 M * faheem__ daniel_hozac: I assume that is set in /etc/vservers/.defaults, but don't see it...
1192830191 M * daniel_hozac vdirbase.
1192830194 M * Bertl will upload the acutal change to the existing state shortly
1192830251 M * daniel_hozac Bertl: looks like there's a line missing there, no function header for the function after do_cow_splice.
1192830261 M * faheem__ Yes, looked there, but it only contains a directory called .pkg
1192830272 M * Bertl yeah, that is because I grep -v ed away the DENTRY_INFO :)
1192830291 M * daniel_hozac hah, okay :)
1192830487 M * daniel_hozac Bertl: so simple, and yet i don't see any problems with it...
1192830712 M * Bertl if that works as expected, we can even scratch the cow mutex again
1192830725 M * daniel_hozac yeah.
1192830753 J * wfire ~wfire@pool-72-86-101-165.aubnin.fios.verizon.net
1192830760 M * Bertl welcome wfire!
1192830781 M * daniel_hozac should we set res = ERR_PTR(-ENOENT) in the /* drop out early */ case as well?
1192830849 M * Bertl probably
1192830898 M * faheem__ I want my vservers to live under /vservers, though. Is my only option to change the vdirbase symlink?
1192830923 M * wfire sorry wrong channel
1192830923 M * daniel_hozac it is certainly the easiest method... of course, you can specify --rootdir /vservers every time you build a guest if you want.
1192830928 P * wfire 
1192831016 Q * FloodServ synthon.oftc.net services.oftc.net
1192831048 M * faheem__ daniel_hozac: That works too. This is all in a script, anyway.
1192831393 Q * julius_ Remote host closed the connection
1192831443 M * faheem__ This doesn't work right, though, even with 
1192831451 M * faheem__ vserver etch_clone build -m clone --hostname etch_clone.duke.earth  --interface eth0:192.168.1.202/24 --  --source /vservers/etch_template
1192831478 M * faheem__ I get bulldog:/var/lib/vservers/etch_clone# ls
1192831482 M * faheem__ dev  etc  etch_template  lost+found  proc
1192831488 M * faheem__ Which is clearly wrong.
1192831765 Q * bonbons Quit: Leaving
1192832105 M * Bertl faheem__: and the template is fine?
1192832105 J * FloodServ services@services.oftc.net
1192832346 M * faheem__ Bertl: Eep, I see the problem. I should be doing /vserver/etch_template/etch_template.
1192832576 Q * fatgoose_ Quit: fatgoose_
1192832836 J * fatgoose ~samuel@76-10-151-220.dsl.teksavvy.com
1192832846 Q * fatgoose Remote host closed the connection
1192832853 J * fatgoose ~samuel@76-10-151-220.dsl.teksavvy.com
1192832861 Q * fatgoose Remote host closed the connection
1192832901 J * fatgoose ~samuel@76-10-151-220.dsl.teksavvy.com
1192832903 Q * fatgoose Remote host closed the connection
1192832978 J * fatgoose ~samuel@76-10-151-220.dsl.teksavvy.com
1192833006 M * Bertl fatgoose: hmm, testing again?
1192833015 M * fatgoose sorry man
1192833019 M * fatgoose colloquy was crashing
1192833030 M * fatgoose I had too many auto-connect auto-rejoin
1192833038 M * Bertl np
1192833580 Q * ntrs_ Ping timeout: 480 seconds
1192833880 J * Fire_Egl FireEgl@4.0.0.0.1.0.0.0.c.d.4.8.0.c.5.0.1.0.0.2.ip6.arpa
1192834557 J * dudester ~martijn@senturparks.xs4all.nl
1192834567 M * Bertl wb dudester!
1192834621 N * dudester the-dude
1192834695 Q * the-dude 
1192834817 P * dowdle Time to head out.  Have a good weekend!
1192835147 M * Bertl Mitch_Bradley, dilinger: okay, I think we have a proper fix for the CoW locking, care to take a look?
1192835203 M * Bertl http://vserver.13thfloor.at/Stuff/OLPC/delta-cow-fix17.diff
1192836438 M * dilinger Bertl: did you test it?
1192836445 M * Bertl yep
1192836482 M * Bertl dilinger: shall I make the entry 'resolved as worksforme' or as 'fixed'?
1192836482 M * dilinger ok
1192836487 M * dilinger not yet
1192836500 M * Bertl okay, so leave it as new?
1192836511 M * daniel_hozac worksforme is typically used for "you're stupid" type of situations ;)
1192836542 M * Bertl okay :)
1192836709 M * dilinger Bertl: it doesn't get listed as fixed until the patch makes it into the kernel
1192836739 M * Bertl okay, got it. tx for the info
1192836838 M * Bertl daniel_hozac: btw, the OLPC bug tracker (trac?) looks quite nice, I think I could live with something like that ... what's your opinion?
1192836893 M * daniel_hozac i've not used it extensively, but it seems fine to me.
1192836909 M * daniel_hozac should be easy to implement too as we're already running trac.
1192836952 M * Bertl yes, just needs the proper skin and logons and such
1192837419 Q * brc Read error: Operation timed out
1192837615 J * brc bruce@megarapido.cliquerapido.com.br
1192837654 J * tanjix ~tanjix@dslb-084-058-008-132.pools.arcor-ip.net
1192837953 Q * tanjix2 Ping timeout: 480 seconds