1319328002 M * chrissbx still doesn't work. 1319328030 M * chrissbx (i.e. /etc/vservers/gamb/apps/vunify/hash/01 -> /usr/vservers/.hash) 1319328070 M * Bertl_oO util-vserver version? 1319328121 M * chrissbx svn 2939 1319328154 M * chrissbx (March 5) 1319328198 M * chrissbx (s/foo/gamb/ in my "foo" examples above for consistency.) 1319328217 M * Bertl_oO okay, and repeating myself, is there anything to unify? 1319328236 M * Bertl_oO i.e. do you have identical files in /usr/vservers ? 1319328237 M * chrissbx I've got a second vserver, named build64, with the same structure and config. 1319328270 M * chrissbx I've successfully unified them before (with the bad config) when their /usr was on the same fs as their root. 1319328281 M * Bertl_oO okay 1319328311 M * chrissbx (du -s /vservers/.hash says about 600MB, du -s /usr/vservers/.hash is a couple kb) 1319328321 M * Bertl_oO well, I don't see any wrong atm, but please have a chat with daniel_hozac when he's around ... 1319328331 M * chrissbx ok 1319328332 M * Bertl_oO nevertheless, it wouldn't hurt to update util-vserver 1319328339 M * chrissbx yeah, I'll do 1319328561 Q * ghislain Quit: Leaving. 1319328669 M * ser Bertl_oO: hey, i completely forgot to ask if these networking issues i have reported some time ago in 3.x were fixed? 1319328697 M * Bertl_oO please remind me, which one? 1319328700 M * ser Bertl_oO: these with resolving cache 1319328743 M * Bertl_oO yes, that should be resolved, and it will probably be improved further shortly 1319328777 M * ser great, so i will test it shortly and report success/failure, thanks a lot 1319328790 M * Bertl_oO excellent 1319329104 M * ser linux-image-3.0.4-vs2.3.1-beng should include these patches? 1319329493 M * ser and one more qyestion, does the stablization process for 3.0.x mean each new kernel in these series will be stable with vserver? 1319331316 M * Bertl_oO after the stabilization, there will be a stable branch for 3.x yes 1319331335 M * Bertl_oO off to bed now ... have a good one everyone! 1319331340 N * Bertl_oO Bertl_zZ 1319331711 M * chrissbx Where's the current SVN? http://svn.linux-vserver.org/svn/util-vserver/ is still at revision 2939 1319331727 M * chrissbx daniel_hozac: ^ 1319332150 M * ser Bertl: I can confirm 3.0.4-vs2.3.1-beng works properly, no resolver cache issues - thanks a lot! 1319335316 J * treaki__ ~treaki@p5B032D7B.dip.t-dialin.net 1319335626 Q * treaki_ Ping timeout: 480 seconds 1319341948 Q * fisted Ping timeout: 480 seconds 1319342154 J * fisted ~fisted@xdsl-87-78-216-204.netcologne.de 1319344999 Q * fisted Remote host closed the connection 1319345022 J * fisted ~fisted@xdsl-87-78-216-204.netcologne.de 1319346788 Q * SwenTjuln Ping timeout: 480 seconds 1319349687 M * chrissbx Ok, noticed the announcement from March 5 of the move to Git. Fine with me, I've been using git-svn anyway:) 1319350335 J * fisted_ ~fisted@xdsl-87-78-210-194.netcologne.de 1319350488 Q * fisted Ping timeout: 480 seconds 1319352680 J * sannes1 ~ace@cm-84.209.106.118.getinternet.no 1319352785 J * ghislain ~AQUEOS@adsl2.aqueos.com 1319355797 M * chrissbx I've upgraded util-vserver to 5c59135ea4cd12a66678b1106cf81050898fa595 (+ a couple patches from me to make it build as deb for me). 1319355824 M * chrissbx Still doesn't hashify /usr dirs. 1319356652 J * guerby ~guerby@nc10d.tetaneutral.net 1319356885 J * bonbons ~bonbons@2001:960:7ab:0:d53:216a:b7c:2643 1319356931 M * daniel_hozac patches like what? 1319356971 M * daniel_hozac where do you mount the guest filesystems? 1319357884 Q * treaki__ Ping timeout: 480 seconds 1319358782 J * treaki__ ~treaki@p5B032D7B.dip.t-dialin.net 1319359200 J * petzsch ~markus@p57B66113.dip.t-dialin.net 1319359600 J * padde_ ~padde@patrick-nagel.net 1319359601 N * DLange Guest14452 1319359610 J * DLange ~DLange@dlange.user.oftc.net 1319359666 Q * Guest14452 Read error: Connection reset by peer 1319359711 Q * padde Ping timeout: 480 seconds 1319359714 N * padde_ padde 1319362022 Q * petzsch Quit: Leaving. 1319363554 N * Bertl_zZ Bertl 1319363559 M * Bertl morning folks! 1319364522 Q * ser Quit: Quit. 1319364568 Q * renihs Ping timeout: 480 seconds 1319364918 Q * brc Ping timeout: 480 seconds 1319365513 J * ser ~ser@host1.tldp.ibiblio.org 1319365648 M * ser good morning, Bertl, and one morning question with 3.0.4: http://pastebin.com/AESwT70F - and the same is with htop, when i run it in the same chcontext, it does not dipslay IOR,IOWR, but it works perefectly in the host or inside any of guests. 1319365702 M * ser in 2.6.36 it was working properly 1319367316 M * Bertl did you set the entries as visible for the spectator context? 1319367340 M * Bertl specifically vmstat 1319367403 M * Bertl (seems to work fine here) 1319367766 Q * fisted_ Remote host closed the connection 1319368104 M * ser Bertl: I cannot understand, sorry, what you mean by setting these entries 1319368212 J * fisted ~fisted@xdsl-87-78-210-194.netcologne.de 1319368668 M * Bertl for exmaple, what does 'showattr /proc/vmstat' give on your system? 1319368733 M * ser "AwH--uic- /proc/vmstat" on both, 2.6.36 and 3.0.4 1319368757 M * ser one displays IO, the second not 1319368763 M * Bertl see, and 'A' means Admin context, 'W' means 'Watch' or spectator context and 'H' means hidden 1319368793 M * Bertl so, you explicitely have 'w' which means that watch/spectator context is not allowed to see it 1319368807 M * Bertl in your 2.6.36, this probably was a bug :) 1319368834 M * Bertl try 'setattr --watch /proc/vmstat' 1319368844 M * Bertl and then try again with iotop 1319368948 M * Bertl I'd also suggest to update to 3.0.7 because of the mainline fixes 1319369038 M * ser OK, I see. "AWH--uic- /proc/vmstat" - "chcontext --xid 1 -- iotop" works now, indeed, but "chcontext --xid 1 -- htop" still does not 1319369069 M * ser htop shows zeros instead of IO 1319369221 M * arekm Bertl: did you have a time to look at Pawels email? 1319369596 Q * Aiken Remote host closed the connection 1319369632 M * Bertl arekm: I did read it, if that's what you're asking, I didn't look into the issue yet 1319370264 Q * sannes1 Ping timeout: 480 seconds 1319370576 J * sannes1 ~ace@cm-84.209.106.118.getinternet.no 1319371254 J * petzsch ~markus@p57B66113.dip.t-dialin.net 1319371675 M * Bertl off for now ... bbl 1319371682 N * Bertl Bertl_oO 1319371705 M * Bertl_oO ser: probably another entry missing, please double check 1319372100 J * brc ~bruce@72.20.27.65 1319373633 Q * petzsch Quit: Leaving. 1319377162 J * fisted_ ~fisted@xdsl-87-78-210-194.netcologne.de 1319377262 Q * fisted Remote host closed the connection 1319380881 Q * fisted_ Remote host closed the connection 1319380895 J * fisted ~fisted@xdsl-87-78-210-194.netcologne.de 1319381486 J * derjohn_mob ~aj@p578EF32F.dip.t-dialin.net 1319381547 Q * fisted Remote host closed the connection 1319381562 J * fisted ~fisted@xdsl-87-78-210-194.netcologne.de 1319382283 Q * FireEgl Ping timeout: 480 seconds 1319382521 J * hparker ~hparker@2001:470:1f0f:32c:beae:c5ff:fe01:b647 1319383017 Q * derjohn_mob Ping timeout: 480 seconds 1319385030 J * derjohn_mob ~aj@p578EF992.dip.t-dialin.net 1319385992 J * derjohn_foo ~aj@p4FFD3137.dip.t-dialin.net 1319386291 Q * derjohn_mob Ping timeout: 480 seconds 1319386707 Q * derjohn_foo Ping timeout: 480 seconds 1319390739 J * derjohn_mob aj@tmo-074-148.customers.d1-online.com 1319391238 Q * derjohn_mob Ping timeout: 480 seconds 1319391336 M * chrissbx daniel_hozac: for my patches, see https://github.com/pflanze/util-vserver 1319391404 M * chrissbx daniel_hozac: I've got two filesystems: /dev/mapper/sda5_crypt which is mounted on / on the host, and /dev/sda6 which is mounted on /usr on the host; 1319391439 M * chrissbx daniel_hozac: then I've got /vservers/gamb and /vservers/build64 which are the roots of the vservers, 1319391448 Q * jeroen__ Ping timeout: 480 seconds 1319391491 M * chrissbx and then I've got /usr/vservers/gamb which is bind mounted onto /usr of gamb and /usr/vservers/build64 which is bind mounted onto /usr of build64. 1319391521 M * chrissbx (using their respective /etc/vservers//fstab) 1319391538 M * chrissbx Also, I did mkdir /usr/vservers/.hash, 1319391582 M * chrissbx and ln -s ../../.defaults/apps/vunify /etc/vservers/gamb/apps/vunify, 1319391594 M * chrissbx and ln -s ../../.defaults/apps/vunify /etc/vservers/build64/apps/vunify, 1319391627 M * chrissbx and ln -s /usr/vservers/.hash etc/vservers/.defaults/apps/vunify/hash 1319391646 M * chrissbx ehr, make this latter line: ln -s /usr/vservers/.hash /etc/vservers/.defaults/apps/vunify/hash 1319391663 M * chrissbx ehr, make this latter line: ln -s /usr/vservers/.hash /etc/vservers/.defaults/apps/vunify/hash/01 1319391856 M * chrissbx Then I run "vserver gamb hashify" and "vserver build64 hashify", but /usr/vservers/.hash stays empty, and the files under /usr inside the vservers have link count 1 (well most of them). 1319391922 J * derjohn_mob ~aj@p4FFD3C90.dip.t-dialin.net 1319391948 M * chrissbx I've also gc'd the files in /vservers/.hash because I thought maybe it's a bug that if vhashify sees a hash in one fs it won't create the same one in another fs, but gc'ing hasn't changed the outcome of vserver hashify. 1319391953 J * jeroen__ ~jeroen@095-097-051-172.static.chello.nl 1319393223 M * daniel_hozac what mounts your filesystems? 1319393658 M * daniel_hozac if you're using the guest's fstab, try vnamespace -e -- vserver hashify 1319394443 Q * fisted Ping timeout: 480 seconds 1319394564 J * fisted ~fisted@xdsl-87-78-214-135.netcologne.de 1319395386 M * chrissbx As mentioned, I bind mount them using the vserver config: using their respective /etc/vservers//fstab 1319395427 M * chrissbx Does that mean "guest's fstab"? 1319395457 M * chrissbx I guess I can see the problem, though. Trying the above. 1319395520 M * chrissbx daniel_hozac: hm, that says "link(): Invalid cross-device link" 'endlessly' 1319395549 M * chrissbx At least that's progress :) 1319395628 J * bergerx ~bergerx@46.196.250.204 1319396308 M * chrissbx Interestingly it has created subdirs in /usr/vservers/.hash 1319396313 M * chrissbx (but no file) 1319396413 M * chrissbx And actually even if it links to the right place, linux won't allow it, ugh. 1319396443 M * chrissbx gives same error: vnamespace -e build64 -- ln /vservers/build64/usr/bin/pod2man /usr/vservers/.hash/foo 1319396501 M * chrissbx This *does* show the same device number: vnamespace -e build64 -- stat /vservers/build64/usr/bin/pod2man /usr/vservers/.hash/|grep Device 1319396597 M * chrissbx Hm. How can I have a different /usr other than using bind mounts? Does this mean unification support just cannot possibly work for more than one filesystem per vserver? 1319396641 M * daniel_hozac it does. 1319396652 M * chrissbx What do you mean? 1319396668 M * daniel_hozac unification works fine for several filesystems. 1319396681 M * chrissbx Several per the same guest? 1319396689 M * daniel_hozac yep. 1319396696 M * chrissbx How do you do that then? 1319396720 M * chrissbx I mean, how do you mount the second filesystem into the guest? 1319396888 M * chrissbx Do you place .hash/ into plain sight of the vserver or what? 1319396971 M * chrissbx Or run unification directly without going through the "vserver" tool, using the paths outside? 1319397000 M * chrissbx Or is there a special mount --bind flag that allows hardlinks? 1319397055 M * daniel_hozac no. 1319397073 M * daniel_hozac probably worth trying to run it manually. 1319397088 M * chrissbx vhashify? 1319397105 M * daniel_hozac yep. 1319397213 J * FireEgl ~FireEgl@173-16-9-169.client.mchsi.com 1319397276 M * chrissbx Has the bevaviour in Linux regarding hardlinks across bind mounts changed? 1319397685 M * chrissbx daniel_hozac: /usr/lib/util-vserver/vhashify /usr/vservers/.hash/ /usr/vservers/gamb/ 1319397693 M * chrissbx Failed to initialize unification for vserver 1319397698 M * chrissbx Using strace, I can see 1319397710 M * chrissbx stat64("/usr/vservers/.hash//vdir", 0xffb1b9f0) = -1 ENOENT (No such file or directory) 1319397712 M * chrissbx a couple times. 1319397721 M * chrissbx Why would it expect vdir there?? 1319397791 M * chrissbx When --help says: /usr/lib/util-vserver/vhashify --manually [-nv] [--] 1319397834 M * chrissbx What is excludelist, the path to a file containing the list? 1319398126 M * daniel_hozac you don't have --manually in the arguments. 1319398136 M * daniel_hozac and yes, exclude list is a file containing the complete list. 1319398192 M * chrissbx Ah. tn:~# touch empty 1319398192 M * chrissbx tn:~# /usr/lib/util-vserver/vhashify --manually /usr/vservers/.hash/ /usr/vservers/gamb/ empty 1319398192 M * chrissbx '--manually' requires '--destination' 1319398238 M * chrissbx --help doesn't say what --destination is 1319398346 M * daniel_hozac --destination is .hash. 1319398423 M * chrissbx /usr/lib/util-vserver/vhashify --manually --destination /usr/vservers/.hash/ /usr/vservers/gamb/ empty 1319398423 M * chrissbx Could not find a place for the hashified files at '/usr/vservers/.hash/'. 1319398520 M * daniel_hozac sorry, /etc/vservers/.defaults/apps/init/vunify/hash 1319398542 M * chrissbx aha 1319398599 M * chrissbx /usr/lib/util-vserver/vhashify --manually --destination /etc/vservers/.defaults/apps/vunify/hash /usr/vservers/.hash/ /usr/vservers/gamb/ empty 1319398599 M * chrissbx read(): Is a directory 1319398657 M * daniel_hozac drop .hash 1319399378 M * chrissbx Ok, that worked. 1319399432 M * chrissbx What's the way forward? Someone on #kernelnewbies thought the invalid cross device link error might be a kernel bug, so I'll send a message to lkml. 1319399537 M * chrissbx Otherwise, I could live with the above, even though that's rather hacky, so I might as well spend the same amount of time it'd take me to make my scripts handle this to fix util-vserver. 1319399597 M * chrissbx I wonder what you mean when you said "it works fine", do you think it should work with my setup? (i.e. kernel bug?) 1319399896 M * daniel_hozac no, the kernel expressly forbids it. 1319399948 M * chrissbx So what did you mean with "works fine"? 1319400021 M * daniel_hozac your setup doesn't. 1319400022 M * daniel_hozac others do. 1319400038 M * chrissbx which others? 1319400059 M * chrissbx I understand that you could have vserver A with one fs, and vserver B with another, without involving mount --bind, and it will work 1319400072 M * chrissbx But if I want to have two filesystems in the same vserver, it can never work. 1319400081 M * chrissbx Do you understand that point? 1319400109 M * chrissbx Because the only way to have two filesystems in the same vserver is by using bind mounts. 1319400159 M * chrissbx (Or, independent mounts, of course, which wouldn't be any better I suppose) 1319400225 M * chrissbx I wonder why the kernel forbids it, doesn't make sense to me. 1319400655 M * daniel_hozac link(2) even mentions it. 1319400820 M * chrissbx Yes (although bind *might* be more relaxed than mount $samedev $anotherdir) 1319400834 M * chrissbx So is there anything I can do for util-vserver? 1319401014 M * chrissbx I'm coding up a hacky logic up in Perl right now (my scripts already are in Perl) 1319401034 M * chrissbx s/hacky/hardcoded for \/usr/ 1319402218 Q * derjohn_mob Ping timeout: 480 seconds 1319402238 J * Aiken ~Aiken@2001:44b8:2168:1000:21f:d0ff:fed6:d63f 1319402568 J * derjohn_mob ~aj@p4FFD3C90.dip.t-dialin.net 1319402816 Q * sannes1 Remote host closed the connection 1319403057 Q * derjohn_mob Ping timeout: 480 seconds 1319403377 J * derjohn_mob ~aj@p4FFD0714.dip.t-dialin.net 1319403448 Q * ircuser-1 Remote host closed the connection 1319403901 J * cuba33ci_ ~cuba33ci@111-240-167-159.dynamic.hinet.net 1319404079 Q * derjohn_mob Ping timeout: 480 seconds 1319404229 Q * cuba33ci Ping timeout: 480 seconds 1319404233 N * cuba33ci_ cuba33ci 1319412152 J * black ~black@02d910f8.bb.sky.com 1319412159 Q * ghislain Quit: Leaving. 1319412670 Q * bonbons Quit: Leaving 1319413243 N * black Hmmm 1319413245 N * Hmmm alalala 1319413245 N * alalala asassdas 1319413274 N * asassdas Black 1319413283 N * Black black 1319414335 Q * bergerx Quit: Leaving