1171497960 J * ph1l0r ~phil@pD95070DD.dip0.t-ipconnect.de 1171497978 M * ph1l0r hi 1171498013 M * Bertl welcome ph1l0r! 1171498199 M * ph1l0r one host with one network card with multiple ip's assigned (eth0:1, :2 etc) 1171498221 M * ph1l0r traffic from virtual servers will go through eth0 and thus have it's macid? 1171498371 M * Bertl yep 1171498393 M * ph1l0r thats goood 1171498411 M * ph1l0r my hoster is checking for macid's 1171498429 M * ph1l0r can't get vmware to work in bridged mode for instance 1171498453 M * ph1l0r vserver and debian work together fine? 1171498462 M * ph1l0r or rather rpm based distro? 1171498479 M * Bertl yes, debian is fine, just avoid the debian kernels and utils 1171498539 M * Bertl (although they are okay for recent releases) 1171498635 M * Bertl daniel_hozac: http://plm.testing.osdl.org/patches/show/Linux-VServer-2.6.19.3-vs2.2.0-rc13 1171498700 M * ph1l0r i am thinking about setting up a server with etch. 1171498709 M * ph1l0r hopefully won't be long until they release it as new stable 1171498947 M * mEDI_S hi Bertl, wat is new in rc13? ;) i miss a changelog hehe 1171499125 M * Bertl http://vserver.13thfloor.at/Experimental/ 1171499134 M * Bertl (it's sorted chronological by default) 1171499212 M * mEDI_S ah thx for the info 1171499231 M * Bertl np 1171499893 J * FireEgl Proteus@2001:5c0:84dc:1:211:9ff:feca:b042 1171500076 J * infowolfe ~infowolfe@c-67-164-195-129.hsd1.ut.comcast.net 1171500171 M * Bertl welcome infowolfe! FireEgl! 1171500184 M * infowolfe hi Bertl 1171500431 M * FireEgl =) 1171500496 Q * bonbons Quit: Leaving 1171500975 Q * infowolfe Read error: Connection reset by peer 1171501300 M * Bertl daniel_hozac: rc13 seems to add a lot of warnings to ia32/64 1171501379 M * Bertl but they seems to be the result of different compilers or so? 1171501405 M * Bertl yes *sigh* I guess I have to submit a zero patch too 1171501813 M * dhansen Bertl: do you still want to be cc'd on the r/o bind mount progress? 1171501821 M * dhansen I've got another 28 patches ready to go 1171502058 M * Bertl yeah, bring it on :) 1171502067 J * infowolfe ~infowolfe@c-67-164-195-129.hsd1.ut.comcast.net 1171502096 M * Bertl dhansen: after all, if it finally gets included, in one or the other way, I'll have to remove it from Linux-VServer :) 1171502109 Q * dna Quit: Verlassend 1171503014 Q * infowolfe Read error: Connection reset by peer 1171503728 Q * mEDI_S Quit: mEDI_S 1171503934 Q * mnemoc Ping timeout: 480 seconds 1171504147 Q * FireEgl Quit: ... 1171504233 J * mEDI_S ~medi@snipah.com 1171504418 J * mnemoc ~amery@kilo105.server4you.de 1171505171 T * Bertl http://linux-vserver.org/ | latest stable 2.0.2.1, 2.0.3-rc1, 2.2.0-rc13/pre4, devel 2.1.1.7.1, 2.3.0.10, stable+grsec 2.0.2.1, 2.2.0-rc12 | util-vserver-0.30.212 | libvserver-1.0.2 & vserver-utils-1.0.3 | He who asks a question is a fool for a minute; he who doesn't ask is a fool for a lifetime -- share the gained knowledge on the Wiki, and we'll forget about the minute ;) 1171505480 J * infowolfe ~infowolfe@c-67-164-195-129.hsd1.ut.comcast.net 1171505621 M * Bertl daniel_hozac: I made a minor change to shiny16 to avoid clashes with arguments ... and I updated it in place, if you already downloaded it, please reload 1171505625 Q * ph1l0r 1171506823 J * cast ~cast@ppp197-9.lns1.adl4.internode.on.net 1171506834 M * Bertl welcome cast! 1171506850 M * cast greetings! i'm back, with more energy for my --barrier question 1171506860 M * Bertl okay ... 1171506872 M * cast now this one is...after i've setattr --barrier, how do i unset it? chattr doesn't understand B 1171506922 M * Bertl --~barrier 1171506937 A * cast nods 1171507244 J * ensc ~irc-ensc@p54B4D2AE.dip.t-dialin.net 1171507952 Q * meandtheshel1 Quit: Leaving. 1171508908 M * cast alright, after looking at the wiki C code examples 1171509098 M * cast ' Using chdir("..") many times' results in it printing Exploit seems to work, but the invocation of /bin/sh is still the /bin/sh inside /var/lib/vservers and its not obvious to me how to get out. now turn on -barrier and when it gets as far as chdir("..") it dies from permission denied. in either case there's nothing in the logs 1171509125 M * cast so --barrier is doing something :) 1171509522 M * Bertl yes, the exploit is broken :) 1171509589 M * Bertl the one you are referring to is one of the earliest chroot escapes used on Linux-VServer 1171509619 M * Bertl there are other escape approaches, some have C code available too 1171509834 M * cast New security context is 666 1171509834 M * cast chmod: changing permissions of `/var/lib/vservers': Operation not permitted 1171509837 M * cast hey nice :) 1171509859 M * cast [that was the result of chcontext --xid 666 -- chmod +x /var/lib/vservers that you told me to do last week] 1171509946 M * cast thanks dude. 1171509953 M * Bertl you're welcome! 1171510295 Q * SNy Ping timeout: 480 seconds 1171511435 J * SNy f2e0027f4d@bmx-chemnitz.de 1171511594 J * gerrit ~gerrit@12.40.236.1 1171512072 J * SNy_ d450e9923a@bmx-chemnitz.de 1171512077 Q * SNy Read error: Connection reset by peer 1171512090 N * SNy_ SNy 1171512609 Q * gerrit Ping timeout: 480 seconds 1171513399 J * gerrit ~gerrit@mobile-166-214-176-161.mycingular.net 1171515135 J * olivierk_ ~olivier@olivierk.org 1171515244 Q * olivierk Ping timeout: 480 seconds 1171515842 J * natero ~nygb63@81.25.79.74 1171515880 M * Bertl welcome natero! 1171515914 Q * natero Remote host closed the connection 1171516029 Q * Guy- Read error: Connection reset by peer 1171516041 J * Guy- 55beZiFNRs@chardonnay.math.bme.hu 1171516689 J * jayme_t ~shfp56@c-24-63-169-160.hsd1.ma.comcast.net 1171516689 J * kWo13w ~breq97@63.146.40.33 1171516689 J * oyrxleq ~xwts58@c-68-57-169-11.hsd1.va.comcast.net 1171516689 J * steveh ~kcoy09@c-68-57-169-11.hsd1.va.comcast.net 1171516689 J * shthedq ~zwie09@cable-213-132-157-104.upc.chello.be 1171516689 J * cellfishc ~tuzv36@c-68-63-38-66.hsd1.fl.comcast.net 1171516689 M * jayme_t SHEMALES DAWG 1171516689 M * jayme_t SHEMALES DAWG 1171516689 P * jayme_t 1171516689 M * kWo13w SHEMALES DAWG 1171516689 M * kWo13w SHEMALES DAWG 1171516689 P * kWo13w 1171516689 M * oyrxleq SHEMALES DAWG 1171516689 M * oyrxleq SHEMALES DAWG 1171516689 P * oyrxleq 1171516690 M * steveh SHEMALES DAWG 1171516690 M * steveh SHEMALES DAWG 1171516690 P * steveh 1171516690 M * shthedq SHEMALES DAWG 1171516690 M * shthedq SHEMALES DAWG 1171516690 P * shthedq 1171516690 M * cellfishc SHEMALES DAWG 1171516690 M * cellfishc SHEMALES DAWG 1171516690 P * cellfishc 1171516690 J * Shakkat ~xoaa65@user-12lcbpo.cable.mindspring.com 1171516690 J * Zell_f ~dngv25@220.181.31.44 1171516690 J * Mandonask ~ufco93@user-12lcbpo.cable.mindspring.com 1171516690 J * EneerOXa ~afqw72@220.181.31.44 1171516690 M * Shakkat SHEMALES DAWG 1171516690 M * Shakkat SHEMALES DAWG 1171516690 P * Shakkat 1171516690 M * Mandonask SHEMALES DAWG 1171516690 M * Mandonask SHEMALES DAWG 1171516690 P * Mandonask 1171516690 J * rmanh CacheFlowS@211.138.91.30 1171516690 J * daboolab CacheFlowS@211.138.91.30 1171516690 J * GillBatep ~aeva31@211.140.192.98 1171516690 J * centuriok ~dlny58@211.140.192.98 1171516690 J * Tashz ~tuzv36@61.144.68.20 1171516690 M * Zell_f SHEMALES DAWG 1171516690 M * Zell_f SHEMALES DAWG 1171516690 P * Zell_f 1171516690 J * ^KidUnixf ~pxik49@61.144.68.20 1171516690 J * c04yo ~jcew21@61.144.68.20 1171516690 Q * EneerOXa autokilled: (FloodServ) You have triggered a network protection Text/Flood. Please stop flooding! (2007/2/15 05.18) 1171516690 M * daboolab SHEMALES DAWG 1171516690 M * daboolab SHEMALES DAWG 1171516690 P * daboolab 1171516690 M * rmanh SHEMALES DAWG 1171516690 M * rmanh SHEMALES DAWG 1171516690 P * rmanh 1171516691 M * c04yo SHEMALES DAWG 1171516691 M * c04yo SHEMALES DAWG 1171516691 P * c04yo 1171516691 M * ^KidUnixf SHEMALES DAWG 1171516691 M * ^KidUnixf SHEMALES DAWG 1171516691 P * ^KidUnixf 1171516691 M * Tashz SHEMALES DAWG 1171516691 M * Tashz SHEMALES DAWG 1171516691 P * Tashz 1171516691 J * jjjjj666z ~fgbp85@203.86.29.188 1171516691 M * GillBatep SHEMALES DAWG 1171516691 M * GillBatep SHEMALES DAWG 1171516691 P * GillBatep 1171516691 M * centuriok SHEMALES DAWG 1171516691 M * centuriok SHEMALES DAWG 1171516691 P * centuriok 1171516691 M * jjjjj666z SHEMALES DAWG 1171516691 M * jjjjj666z SHEMALES DAWG 1171516691 P * jjjjj666z 1171516692 J * Tomlinsof ~elvq57@218.30.84.110 1171516692 M * Tomlinsof SHEMALES DAWG 1171516692 M * Tomlinsof SHEMALES DAWG 1171516692 P * Tomlinsof 1171516694 J * ggggm ~zees68@c-24-60-60-0.hsd1.ma.comcast.net 1171516694 J * Tru```y ~pxik49@c46-1.icpnet.pl 1171516694 J * StylesPl ~evyo09@c46-1.icpnet.pl 1171516694 J * Farlander ~axjs47@c46-1.icpnet.pl 1171516695 M * ggggm SHEMALES DAWG 1171516695 M * ggggm SHEMALES DAWG 1171516695 P * ggggm 1171516696 J * jackkc ~orps80@81.25.79.74 1171516697 M * Tru```y SHEMALES DAWG 1171516697 M * Tru```y SHEMALES DAWG 1171516697 P * Tru```y 1171516697 M * StylesPl SHEMALES DAWG 1171516697 M * StylesPl SHEMALES DAWG 1171516697 P * StylesPl 1171516697 M * Farlander SHEMALES DAWG 1171516697 M * Farlander SHEMALES DAWG 1171516697 P * Farlander 1171516701 J * tydelz ~mvtb91@81.25.79.74 1171516701 M * tydelz SHEMALES DAWG 1171516701 M * tydelz SHEMALES DAWG 1171516701 P * tydelz 1171516701 J * mistik1t ~ehqu22@81.25.79.74 1171516701 M * mistik1t SHEMALES DAWG 1171516701 M * mistik1t SHEMALES DAWG 1171516701 P * mistik1t 1171516701 Q * jackkc autokilled: (FloodServ) You have triggered a network protection Text/Flood. Please stop flooding! (2007/2/15 05.18) 1171516794 M * Bertl I'm sure that person tried to tell us something :) 1171516928 J * ravidgemole ~ravidgemo@ravidgemole.netop.oftc.net 1171517192 J * DoberMann_ ~james@86.196.164.254 1171517277 P * ravidgemole 1171517299 Q * DoberMann[ZZZzzz] Ping timeout: 480 seconds 1171519464 M * Bertl okay, I'm off to bed now ... have a good one everyone! cya! 1171519469 N * Bertl Bertl_zZ 1171519837 J * FireEgl Proteus@68.220.222.136 1171521434 Q * gerrit Ping timeout: 480 seconds 1171521552 Q * s0undt3ch Ping timeout: 480 seconds 1171521561 J * s0undt3ch ~s0undt3ch@80.69.34.154 1171522558 N * DoberMann_ DoberMann 1171524160 J * gab ~gab@158.36.45.236 1171524316 Q * mEDI_S Ping timeout: 480 seconds 1171524474 Q * Aiken Quit: Leaving 1171524724 N * DoberMann DoberMann[PullA] 1171525522 J * olivierk ~olivier@olivierk.org 1171525630 Q * olivierk_ Ping timeout: 480 seconds 1171525992 Q * Piet Quit: Piet 1171526353 J * Loki|muh_ loki@satanix.de 1171526454 J * mEDI_S ~medi@snipah.com 1171526519 Q * comfrey_ Remote host closed the connection 1171526531 Q * comfrey__ Remote host closed the connection 1171526531 J * comfrey ~comfrey@70.91.185.84 1171526534 Q * DreamerC Remote host closed the connection 1171526549 J * DreamerC ~dreamerc@125-225-101-89.dynamic.hinet.net 1171526663 Q * Loki|muh Ping timeout: 480 seconds 1171526663 N * Loki|muh_ Loki|muh 1171527031 J * comfrey_ ~comfrey@70.91.185.84 1171528428 N * DoberMann[PullA] DoberMann 1171529835 J * muuhDBX ~foo@a213-22-7-80.cpe.netcabo.pt 1171530831 J * dlezcano ~dlezcano@blueice4n2.uk.ibm.com 1171531951 J * bonbons ~bonbons@83.222.37.103 1171533081 Q * mEDI_S Ping timeout: 480 seconds 1171534000 J * dna ~naucki@240-219-dsl.kielnet.net 1171534177 J * mEDI_S ~medi@snipah.com 1171534473 J * lilalinux ~plasma@80.69.41.2 1171535756 Q * bonbons Quit: Leaving 1171535840 J * bonbons ~bonbons@83.222.38.237 1171535850 Q * michal` Ping timeout: 480 seconds 1171535929 J * meandtheshell ~markus@85-125-231-206.dynamic.xdsl-line.inode.at 1171536229 J * michal` ~michal@www.rsbac.org 1171536574 Q * lilalinux Remote host closed the connection 1171536775 J * lilalinux ~plasma@dslb-084-058-204-021.pools.arcor-ip.net 1171537024 Q * bronson Ping timeout: 480 seconds 1171537099 Q * cehteh Server closed connection 1171537122 J * cehteh ~ct@pipapo.org 1171537452 Q * lilalinux Quit: Leaving 1171537754 J * DavidS ~david@chello062178045213.16.11.tuwien.teleweb.at 1171538171 Q * mEDI_S Ping timeout: 480 seconds 1171538591 J * Viper0482 ~Viper0482@p57AED34F.dip.t-dialin.net 1171538635 Q * Viper0482 1171539042 P * muuhDBX 1171539793 J * gerrit ~gerrit@mobile-166-214-157-144.mycingular.net 1171541735 Q * brcc Server closed connection 1171541737 J * brcc bruce@i.am.someasshole.com 1171542117 Q * shedi Quit: Leaving 1171543691 Q * gerrit Ping timeout: 480 seconds 1171543746 J * mjt ~mjt@nat.corpit.ru 1171543784 J * dna_ ~naucki@240-219-dsl.kielnet.net 1171544194 Q * dna Ping timeout: 480 seconds 1171544271 Q * sannes Server closed connection 1171544274 J * sannes ace@har.sagt.no 1171545451 J * lilalinux ~plasma@dslb-084-058-204-021.pools.arcor-ip.net 1171545866 J * ema ~ema@lart.galliera.it 1171546599 Q * sladen Ping timeout: 480 seconds 1171546854 J * sladen paul@starsky.19inch.net 1171547515 J * gerrit ~gerrit@mobile-166-214-187-033.mycingular.net 1171547860 N * Bertl_zZ Bertl 1171547865 M * Bertl morning folks! 1171548375 J * pstader ~phil@pD95041DD.dip0.t-ipconnect.de 1171548376 Q * ema Quit: leaving 1171548380 M * pstader hi there 1171548397 M * matti Bertl: :) 1171548404 M * Bertl welcome pstader! 1171548430 M * matti Bertl: Any idea, how to determine socket type (for example: PF_UNIX) if I have only a socket descriptor? 1171548473 M * Bertl getsock/peername 1171548744 M * waldi Bertl: got unkillable processes on sparc with 2.2.0-rc3 1171548747 M * waldi s/rc/pre/ 1171548844 M * pstader can i use the latest vserver patch for 2.6.20 together with the vserver tools from debian etch? 1171548971 M * waldi yes 1171549000 M * pstader awesome 1171549152 M * Bertl waldi: not there with 2.6.19.3? 1171549176 M * waldi dunno 1171549183 M * waldi also there with 2.6.18 1171549256 M * DavidS hi Bertl! 1171549277 M * Bertl waldi: hmm, let's check the reaper fix then 1171549285 M * Bertl (or update to pre4) 1171549295 M * Bertl hey DavidS! LTNS! 1171549298 M * waldi Bertl: i don't think it is a reaper problem 1171549325 M * Bertl waldi: okay, what does debugging say? 1171549335 M * Bertl is the signal sent? 1171549349 M * Bertl what about vkill? does it work? 1171549386 M * waldi hrm, it currently runs the non-debugging version 1171549421 M * waldi root@zee:~# vkill -c 3 -s 9 -- 11240 1171549421 M * waldi root@zee:~# vps aux | grep 11240 1171549421 M * waldi 60015 11240 3 build-kilian 100 0.0 829248 3632 ? RN 06:32 171:34 dpkg-query --search libstdc++.so.6 libm.so.6 libgcc_s.so.1 libc.so.6 1171549445 M * waldi root 23322 0 MAIN 0.0 0.0 0 0 ? Ds 09:10 0:00 [zsh] 1171549448 M * waldi root 24460 3 build-kilian 0.0 0.0 0 0 ? D 09:11 0:00 [vcontext] 1171549456 M * waldi this was my last vserver $name enter 1171549477 M * Bertl those D processes are stuck in device I/O 1171549483 M * Bertl so they are not killable 1171549513 M * Bertl the question is _why_ they are stuck, and the anser is usually, because of some kind of kernel panic/trace 1171549532 M * waldi nothing in the kernel log 1171549554 M * waldi hmm, lets try to get a kernel stack trace for them 1171549611 Q * lilalinux Remote host closed the connection 1171549637 M * yang morning Bertl 1171549700 M * Bertl hey yang! 1171549719 M * waldi Bertl: a task is also set uninterruptible if it gots stuck in a semaphore 1171549763 J * lilalinux ~plasma@dslb-084-058-204-021.pools.arcor-ip.net 1171549780 M * sannes Any known problems with 2.3.0.9 and 2.6.20? Just wondering, have been running it on a semi-production server for two days .. and was thinking maybe I should go ahead and put it on some other production servers... :) 1171549800 M * waldi *gna* the sparc kernels lacks magic sysrq 1171549845 A * waldi gets some LART 1171549866 M * Bertl sannes: no known issues ... 1171549917 M * Bertl waldi: right, what filesystem, btw? 1171549936 M * waldi ext3 1171549947 M * Bertl (because jfs was broken last time I checked, regarding locking) 1171549950 M * sannes Bertl: I'm too spoiled :) 1171549966 Q * lilalinux 1171550042 M * waldi Bertl: hmm, it is not normal that a process in uninterrupible sleep lacks any memory mapping? 1171550220 M * pstader another question. should i go 64bit for the host even when i don't need 64bit for vservers? 1171550227 M * waldi yes 1171550232 M * eyck yes 1171550252 M * pstader my server is a core2duo. should be 64bit capable i guess 1171550262 J * lilalinux ~plasma@dslb-084-058-204-021.pools.arcor-ip.net 1171550263 Q * lilalinux 1171550458 J * lilalinux ~plasma@dslb-084-058-204-021.pools.arcor-ip.net 1171550508 M * mjt i wonder why use 64bits if not needed 1171550740 M * cast because you get confused when your tx/rx counters loop 1171550759 M * mjt that's hardly a reason 1171550791 M * mjt i understand using 64bits on a machine with >2Gb (or, really, >4Gb) memory is a good thing 1171550795 M * waldi linux/x86_64 knows how to use an iommu, it knows about numa 1171550811 M * waldi i386 does not 1171550835 M * mjt iommu? 1171550836 M * waldi (and yes, you want the knowledge about numa if running opterons or power) 1171550854 M * mjt core2duo != opteron or power 1171550875 M * waldi 64bits != core2duo 1171550913 M * mjt original question was whenever to use 32 or 64bits kernel on core2duo cpu 1171550938 M * mjt which isn't opteron or power and has nothing to do with numa and that stuff. 1171550942 M * waldi and? your question was generic 1171550975 M * cast openssl seems to go alot faster for certain operations i've noticed :) 1171550977 M * mjt well... yes. I wasn't clear 1171551005 M * waldi and in general you want a 64bit kernel 1171551005 M * mjt i was wondered why it has been suggested to pstader to go with 64bits instead of 32bits 1171551023 M * mjt but... why? 1171551027 M * waldi on x86_64 it is also faster 1171551049 M * mjt not necessary faster 1171551083 M * mjt i mean, if the kernel is 64 and userspace is 32, 32<=>64 structure conversion logic for syscalls takes something too 1171551112 M * mjt switching to 64bits userspace is another story 1171551132 M * mjt after all, it requires more memory to store pointers ;) 1171551141 M * waldi no, most structs are compatible 1171551144 M * Bertl mjt: some/most counters in the kernel are 64bit by now 1171551168 M * Bertl mjt: just consider simple operations like increment or decrement 1171551168 M * waldi and x86-64 uses the same address space for the userland and kernel 1171551191 M * Bertl mjt: they will require 2-5 times the cpu cycles on 32bit 1171551224 M * Bertl mjt: the iommu and 48bit address space is another good reason for 64bit kernels 1171551243 M * waldi i'm not sure, but doesn't x86-64 use registers for arguments in the normal calling convention? 1171551244 Q * gab Quit: Leaving 1171551269 M * Bertl waldi: so can x86 but for x86_64 you have a lot more registers :) 1171551396 M * pstader sounds all very interesting hehe 1171551403 M * pstader too bad i don't understand most ;-) 1171551439 M * Bertl well, ask if you do not understand stuff (see topic) 1171551455 M * pstader na it's cool hehe. i figured i'll use 32bit for core2duo 1171551461 M * pstader since it's not a true 64bit processor 1171551469 M * waldi mjt: you usualy want a kernel which matches the native size. this is not true for the userland. for example 32bit powerpc userspacecode is usualy faster than 64bit 1171551471 M * pstader like an opteron 1171551484 M * waldi it is 1171551497 M * Bertl pstader: core duo is the first 'true' 64bit cpu 1171551506 M * waldi Bertl: you missed the 2 1171551515 M * pstader oh joy. 1171551515 M * Bertl yup, tx 1171551516 M * waldi core duo don't even supports long mode 1171551525 M * waldi (*gna*) 1171551526 M * Bertl core duo 2 1171551530 M * pstader i'll give 64bits a shot 1171551537 M * waldi Bertl: its called core 2 duo 1171551538 M * pstader if it doesn't work i can go back anytime i guess 1171551539 M * Bertl core2/duo :) 1171551541 M * mjt oh well 1171551549 J * shedi ~siggi@ftth-237-144.hive.is 1171551552 M * pstader no serious business here 1171551561 M * pstader just few websites and a bf2 gameserver ;-) 1171551589 M * waldi Bertl: i want a cell cpu. the vector coprocs have 127 general purpose registers a 256bit 1171551607 M * mjt waldi: you want to use them directly? 1171551627 M * mjt ie, writing in a cell assembly language 1171551628 M * mjt ? 1171551632 M * cast hmm, ibm make high performance fortran compilers for the cell? 1171551643 M * waldi mjt: gcc may be enough 1171551644 A * cast investigates 1171551653 M * mjt heh ok ;) 1171551662 M * waldi i don't know if it can make use of this amount of registers 1171551680 M * Bertl waldi: like ia64? too many registers to make good use of them? 1171551709 M * waldi ia64 have too much other problems 1171551724 M * waldi i think the cell can make use of them 1171551730 M * waldi it is a vector processor 1171551731 M * Bertl waldi: I'd prefer the 3 ppcs from the xbox360 over a PS3 with cell :) 1171551772 M * waldi i don't because i can't use the 3 ppcs from the xbox360 but i can use the cell in the ps3 1171551798 J * muuhDBX ~foo@a213-22-7-80.cpe.netcabo.pt 1171551803 M * Bertl waldi: well, you could, if it wasn't M$ :) 1171551813 M * waldi maybe 1171551824 M * mjt xbox360? that's the one that uses GPU memory for RAM? 1171551860 M * Bertl I heard it the other way round 1171551873 M * Bertl i.e. GPU can use some ram for textures 1171551888 M * pstader ia64 or amd64? 1171551899 M * pstader thought those two were just different names for basically the same thing 1171551903 M * mjt doesn't it have only one kind of memory? 1171551905 M * waldi pstader: if you don't know the answer, you don't want ia64 1171551909 M * pstader hehe 1171551921 M * waldi ia64 is a complete different architecture 1171551933 M * Bertl pstader: what you mean is emt64 1171551937 M * pstader it's itanium yes 1171551939 M * mjt pstader: amd64 and em64t are basically the same thing 1171551940 M * waldi amd64 (also called x86_64) is an extension of x86 1171551946 M * pstader so amd64 for core2duo hehe 1171551946 M * pstader funny 1171551960 M * pstader jepp emt64 or something 1171551960 M * Bertl pstader: intel calls it emt64 1171551984 Q * cdrx Quit: Leaving 1171551989 J * cdrx ~legoater@cap31-3-82-227-199-249.fbx.proxad.net 1171551996 M * Bertl pstader: but yes, amd set the specs 1171552011 Q * cdrx 1171552015 J * cdrx ~legoater@cap31-3-82-227-199-249.fbx.proxad.net 1171552031 M * Bertl waldi: hmm, [] denotes kernel threads, no? 1171552050 M * waldi Bertl: yes, this is the usual convention 1171552052 M * Bertl waldi: i.e. threads with no parent, set 1171552074 M * waldi and they lack any memory mapping 1171552080 Q * cdrx 1171552085 M * Bertl your D processes use that too, so I'm abck at my reaper theory? 1171552095 M * waldi abck? 1171552107 M * Bertl *shuffle* 1171552112 M * waldi "back" 1171552116 M * Bertl bingo! 1171552130 J * cdrx ~legoater@cap31-3-82-227-199-249.fbx.proxad.net 1171552188 M * waldi hmm 1171552547 M * waldi Bertl: sometimes they don't loose there memory mappings: 1171552547 M * waldi root 28070 0.0 0.0 9728 3352 ? Ds 09:22 0:00 sshd: root@pts/11 1171552631 J * CHTEKK ~chtekk@62.48.110.172 1171552670 M * CHTEKK lo all :) Bertl, quick question: what's the format for dx_limit_t's space_used and _total? in kilobytes or bytes? 1171552671 M * Bertl welcome CHTEKK! 1171552688 M * Bertl blocks 1171552703 M * Bertl hmm, no, we changed that to kb at some point IIRC 1171552761 M * CHTEKK I hope so, having it in KBs would be good :) 1171552764 Q * gerrit Ping timeout: 480 seconds 1171553072 J * infowolfe_ ~infowolfe@c-67-164-195-129.hsd1.ut.comcast.net 1171553081 Q * infowolfe Ping timeout: 480 seconds 1171553280 Q * [PUPPETS]Gonzo Quit: Serverwechsel 1171553295 J * [PUPPETS]Gonzo gonzo@langweiligneutral.deswahnsinns.de 1171553937 J * gerrit ~gerrit@mobile-166-217-045-183.mycingular.net 1171554801 Q * meandtheshell Quit: Leaving. 1171554996 M * Bertl waldi: okay, a strack trace of such a process, debugging info from a pre4 kernel would be nice ... 1171555005 M * Bertl have to leave now, will be back later ... 1171555011 N * Bertl Bertl_oO 1171555226 J * meandtheshell ~markus@85-125-230-203.dynamic.xdsl-line.inode.at 1171556432 M * pstader lucky me. the 64bit rescue system lacks the driver for the sata controller the only disk in my server is connected to hehe 1171556453 M * pstader wonder how long it will take them to update their rescue system. 1171557162 M * id23 greetings earthlings .... 1171557956 J * stefani ~stefani@flute.radonc.washington.edu 1171558034 J * bronson ~bronson@adsl-75-36-145-145.dsl.pltn13.sbcglobal.net 1171558438 J * jmcaricand ~kvirc@d83-179-131-109.cust.tele2.fr 1171558479 J * paulliu ~paulliu@171.189.192.210.dynamic.ttn.net 1171558758 P * paulliu 1171559424 Q * jmcaricand Quit: KVIrc 3.2.4 Anomalies http://www.kvirc.net/ 1171559985 P * muuhDBX 1171560106 N * DoberMann DoberMann[PullA] 1171560182 J * olivierk_ ~olivier@olivierk.org 1171560294 Q * olivierk Ping timeout: 480 seconds 1171561030 Q * dlezcano Read error: Connection reset by peer 1171561739 Q * FireEgl Quit: ... 1171562680 Q * stefani Ping timeout: 480 seconds 1171563318 N * DoberMann[PullA] DoberMann 1171563564 J * stefani ~stefani@flute.radonc.washington.edu 1171565491 Q * lilalinux Remote host closed the connection 1171565949 Q * dhansen Remote host closed the connection 1171567328 M * CHTEKK uhmmm disk limits.. uhmmm 1171567341 M * CHTEKK I've managed to set them, the files are correctly xid-tagged 1171567367 M * CHTEKK when starting the vserver the limits are correctly set (ie the actual usages calculated and passed as used to the struct, the max passed as totals etc) 1171567384 M * CHTEKK and the dx utility shows the values ok (that basically just directly does the needed syscalls) 1171567427 M * CHTEKK still, if ie I set space_used to 258000 and space_total to 300000 1171567453 M * CHTEKK and then I entered the vserver and started downloading a gentoo img just for test... and it grew up to 96 mb until I stopped it myself 1171567472 M * CHTEKK cause that surely was over the set limit... the xid of the file was correct, during download and after 1171567481 M * CHTEKK still, the limits don't seem to limit anything at all :S 1171567519 M * CHTEKK a dx_limit_get gives me exactly the same limits as I've dx_limit_set'ed them before downloading the iso, so it didn't register any change... why? anyone an idea? 1171567997 M * sc0tt i think it depends what filesystem you suse 1171568004 M * sc0tt s/suse/use/ 1171568024 M * CHTEKK I'm using xfs on that partition 1171568029 M * CHTEKK now I'm off to eat, bbiab! 1171568190 N * DoberMann DoberMann[PullA] 1171568238 J * jmcaricand ~kvirc@d83-179-213-3.cust.tele2.fr 1171568424 J * marcfiu ~mef@aegis.CS.Princeton.EDU 1171568649 Q * gerrit Ping timeout: 480 seconds 1171569392 M * daniel_hozac Bertl_oO: 2.2.0-rc13 seems to have a bad version of the reaper fix. 1171569403 M * daniel_hozac (the one with the printk) 1171569804 J * gerrit ~gerrit@mobile-166-214-051-125.mycingular.net 1171569866 Q * jmcaricand Quit: KVIrc 3.2.4 Anomalies http://www.kvirc.net/ 1171570356 J * fb_ fback@red.fback.net 1171570474 Q * fb Ping timeout: 480 seconds 1171570517 M * CHTEKK back 1171570544 M * CHTEKK hi daniel_hozac :) might you have any idea wrt the disk limits? is there anything that needs to be done to have them enforced or whatever? 1171570552 M * daniel_hozac tagxid 1171570565 M * CHTEKK done 1171570605 M * CHTEKK partition is mounted tagxid, the files of /vservers/test1/ are all correctly xid-tagged (checked with lsxid), and I've added and set the limit with the correct values on /vserveres/test1/ 1171570632 M * CHTEKK yet, it doesn't seem to update the used value (unless I manually do dx_limit_set again); and I can happily go over my limit when doing stuff inside the vserver 1171570643 M * CHTEKK BUT df -aTh actually shows the correct amount 1171570666 M * CHTEKK and it's like 352mb of 352, 100% usage, but I can still just happily continue to do stuff and download/create new files etc 1171570839 M * daniel_hozac humm, what kernel? 1171570862 M * CHTEKK 2.6.19-vs2.2.0-rc12-gentoo 1171570863 M * daniel_hozac it does seem like xfs is lacking the ENOSPC. 1171570901 M * daniel_hozac actually, oh right, xfs doesn't support disk limits. 1171570905 M * CHTEKK which means? :) kernel bug in mainline or vserver-patch? 1171570907 M * CHTEKK ah :) 1171570916 M * CHTEKK so which fs do support them? 1171570934 M * daniel_hozac ext[234], reiserfs and jfs. 1171571084 M * CHTEKK cooool, all of them save the one I'm using :D 1171571122 M * CHTEKK hrmmm never used jfs, am not really keen on reiserfs, ext2... no, and ext3 hasn't excited me particularly lately 1171571137 M * CHTEKK especially on a 2.4tb partition ext3's occasional fscks are quite bothersome 1171571160 M * CHTEKK jfs... jfs... anyone can tell me smt about it? you almost never read of it around... 1171571175 M * CHTEKK I know IBM did it, but have no idea on how speedy or reliable it is, or in what it excels 1171571205 M * daniel_hozac http://en.wikipedia.org/wiki/IBM_Journaled_File_System_2_%28JFS2%29 1171571228 M * CHTEKK yeah I'm reading that too :) 1171571251 J * dlezcano ~dlezcano@AToulouse-252-1-54-66.w83-200.abo.wanadoo.fr 1171571269 M * CHTEKK ohhmmm reading the final comment there makes it look like some sort of "great hidden candy" :) I'll have to try it 1171571281 M * CHTEKK had any experience with it @ daniel_hozac ? 1171571286 M * daniel_hozac no. 1171571298 M * daniel_hozac i'm an ext3 person. 1171571412 M * CHTEKK ok thanks a lot for the info, I'll try jfs then :) 1171571675 M * Hollow we need xfs disk limits :) 1171571703 M * Hollow i already told bertl to test all xfs stuff, since i don't use any other filesystem 1171571918 M * CHTEKK hehe would probably be cool to have that, though if it's a mainline kernel feature that's needed, that may be a lot of work? /me has no clue about this ;) 1171572164 Q * DavidS Quit: Leaving. 1171572193 M * daniel_hozac i suppose it really shouldn't be that hard. 1171572206 M * daniel_hozac xfs already supports group/user quota, right? 1171572215 J * olivierk ~olivier@olivierk.org 1171572229 M * CHTEKK yes it does 1171572247 A * matti pokes CHTEKK with soft coussins. 1171572257 M * matti Nobody expects matti! 1171572258 M * matti ;D 1171572290 M * daniel_hozac hehe 1171572308 M * CHTEKK heh :D hi matti 1171572312 M * matti ;) 1171572316 M * CHTEKK hmm ok https://forums.gentoo.org/viewtopic-t-380102-highlight-jfs+reliable.html isn't a great indicator for jfs 1171572318 M * matti CHTEKK: jfs only jfs2. 1171572324 Q * olivierk_ Ping timeout: 480 seconds 1171572329 M * matti CHTEKK: First jfs is... iss..... well... ;p 1171572388 M * CHTEKK i really like xfs so far, so if disk limit support on that could come quite soon, I'd just continue using that 1171572405 M * CHTEKK where soon can be a month or so too, don't have any need to have ti working NOW 1171572669 M * daniel_hozac hmm, you sure xfs supports regular user/group quotas? 1171572723 M * daniel_hozac i can't find any of those macros in fs/xfs. 1171572995 M * CHTEKK not regular maybe, they support them, with a compatible format afaik, but iirc they have their own way to do it 1171573010 M * CHTEKK you need to mount the partition with something like "xfsquota" or whatever iirc 1171573214 M * CHTEKK or not... it should support standard usrquota,grpquota mounting et all 1171573232 M * CHTEKK the quota option is only needed when you want quotas with xfs being your / partition 1171573252 M * CHTEKK and that's a bootflag, no mount flag 1171573287 M * Hollow xfs stores quota in metadata not in quota.* files iirc 1171573294 M * CHTEKK XFS does all quota checks internally, and does not need the quota script added to the boot runlevel. 1171573325 M * CHTEKK yup according to stuff I'm reading it does the calculations internally and activates them at boot, you only need to do edquota to edit the quotas, all the rest is done by the fs 1171573638 Q * meebey Remote host closed the connection 1171575135 J * DreamerC_ ~dreamerc@125-225-101-208.dynamic.hinet.net 1171575400 Q * DreamerC Read error: Connection reset by peer 1171575583 N * Bertl_oO Bertl 1171575587 M * Bertl back now .. 1171576025 Q * duckx Remote host closed the connection 1171576190 J * meebey meebey@booster.qnetp.net 1171576692 M * Bertl CHTEKK: I guess we will spend a little time on shared disk limits for xfs and similar 1171576713 M * Bertl (but no guarantees yet, as the XFS code is quite unreadable :) 1171576728 M * Bertl and of course, we will need a bunch of testers ... 1171576799 M * Bertl daniel_hozac: okay, will fix that ... tx 1171576864 J * olivierk_ ~olivier@olivierk.org 1171576921 M * CHTEKK Bertl, welcome back :) that would be great, and I'd be happy to test that ;) and Hollow too I imagine 1171576972 M * Hollow yep.. as i said.. i can always test xfs 1171576974 Q * olivierk Ping timeout: 480 seconds 1171577254 Q * bj_ saturn.oftc.net osmotic.oftc.net 1171577254 Q * gerrit saturn.oftc.net osmotic.oftc.net 1171577254 Q * marcfiu saturn.oftc.net osmotic.oftc.net 1171577254 Q * stefani saturn.oftc.net osmotic.oftc.net 1171577254 Q * [PUPPETS]Gonzo saturn.oftc.net osmotic.oftc.net 1171577254 Q * brcc saturn.oftc.net osmotic.oftc.net 1171577254 Q * cehteh saturn.oftc.net osmotic.oftc.net 1171577254 Q * comfrey_ saturn.oftc.net osmotic.oftc.net 1171577254 Q * Loki|muh saturn.oftc.net osmotic.oftc.net 1171577254 Q * Guy- saturn.oftc.net osmotic.oftc.net 1171577254 Q * ensc saturn.oftc.net osmotic.oftc.net 1171577254 Q * mnemoc saturn.oftc.net osmotic.oftc.net 1171577254 Q * rob-84x^ saturn.oftc.net osmotic.oftc.net 1171577255 Q * hardwire saturn.oftc.net osmotic.oftc.net 1171577255 Q * puck saturn.oftc.net osmotic.oftc.net 1171577255 Q * sid3windr saturn.oftc.net osmotic.oftc.net 1171577255 Q * mjt saturn.oftc.net osmotic.oftc.net 1171577255 Q * Hunger saturn.oftc.net osmotic.oftc.net 1171577255 Q * Johnnie saturn.oftc.net osmotic.oftc.net 1171577255 Q * nebuchadnezzar saturn.oftc.net osmotic.oftc.net 1171577255 Q * waldi saturn.oftc.net osmotic.oftc.net 1171577255 Q * pusling saturn.oftc.net osmotic.oftc.net 1171577255 Q * yang saturn.oftc.net osmotic.oftc.net 1171577255 Q * click saturn.oftc.net osmotic.oftc.net 1171577255 Q * Medivh saturn.oftc.net osmotic.oftc.net 1171577255 Q * fosco saturn.oftc.net osmotic.oftc.net 1171577255 Q * phreak`` saturn.oftc.net osmotic.oftc.net 1171577255 Q * TrueBrain saturn.oftc.net osmotic.oftc.net 1171577255 Q * mcp saturn.oftc.net osmotic.oftc.net 1171577255 Q * Radiance saturn.oftc.net osmotic.oftc.net 1171577255 Q * Wonka saturn.oftc.net osmotic.oftc.net 1171577255 Q * ard saturn.oftc.net osmotic.oftc.net 1171577255 Q * kaner saturn.oftc.net osmotic.oftc.net 1171577255 Q * mountie saturn.oftc.net osmotic.oftc.net 1171577255 Q * Greek0 saturn.oftc.net osmotic.oftc.net 1171577255 Q * tokkee saturn.oftc.net osmotic.oftc.net 1171577255 Q * fs saturn.oftc.net osmotic.oftc.net 1171577255 Q * DreamerC_ saturn.oftc.net osmotic.oftc.net 1171577255 Q * sannes saturn.oftc.net osmotic.oftc.net 1171577255 Q * s0undt3ch saturn.oftc.net osmotic.oftc.net 1171577255 Q * m`m`h saturn.oftc.net osmotic.oftc.net 1171577255 Q * ntrs saturn.oftc.net osmotic.oftc.net 1171577255 Q * baldy saturn.oftc.net osmotic.oftc.net 1171577255 Q * dlezcano saturn.oftc.net osmotic.oftc.net 1171577255 Q * fb_ saturn.oftc.net osmotic.oftc.net 1171577255 Q * bronson saturn.oftc.net osmotic.oftc.net 1171577255 Q * infowolfe_ saturn.oftc.net osmotic.oftc.net 1171577255 Q * cdrx saturn.oftc.net osmotic.oftc.net 1171577255 Q * shedi saturn.oftc.net osmotic.oftc.net 1171577255 Q * pstader saturn.oftc.net osmotic.oftc.net 1171577255 Q * bonbons saturn.oftc.net osmotic.oftc.net 1171577255 Q * comfrey saturn.oftc.net osmotic.oftc.net 1171577255 Q * DoberMann[PullA] saturn.oftc.net osmotic.oftc.net 1171577255 Q * ruskie saturn.oftc.net osmotic.oftc.net 1171577255 Q * eyck saturn.oftc.net osmotic.oftc.net 1171577255 Q * matti saturn.oftc.net osmotic.oftc.net 1171577255 Q * Adrinael_ saturn.oftc.net osmotic.oftc.net 1171577255 Q * derjohn saturn.oftc.net osmotic.oftc.net 1171577255 Q * olivierk_ saturn.oftc.net osmotic.oftc.net 1171577255 Q * meebey saturn.oftc.net osmotic.oftc.net 1171577255 Q * meandtheshell saturn.oftc.net osmotic.oftc.net 1171577255 Q * CHTEKK saturn.oftc.net osmotic.oftc.net 1171577255 Q * sladen saturn.oftc.net osmotic.oftc.net 1171577255 Q * dna_ saturn.oftc.net osmotic.oftc.net 1171577255 Q * michal` saturn.oftc.net osmotic.oftc.net 1171577255 Q * SNy saturn.oftc.net osmotic.oftc.net 1171577255 Q * rw23 saturn.oftc.net osmotic.oftc.net 1171577255 Q * blizz_ saturn.oftc.net osmotic.oftc.net 1171577255 Q * Hollow saturn.oftc.net osmotic.oftc.net 1171577255 Q * nox saturn.oftc.net osmotic.oftc.net 1171577255 Q * weasel saturn.oftc.net osmotic.oftc.net 1171577255 Q * nou saturn.oftc.net osmotic.oftc.net 1171577255 Q * badari saturn.oftc.net osmotic.oftc.net 1171577255 Q * glut saturn.oftc.net osmotic.oftc.net 1171577255 Q * morfoh saturn.oftc.net osmotic.oftc.net 1171577255 Q * bon` saturn.oftc.net osmotic.oftc.net 1171577255 Q * doener saturn.oftc.net osmotic.oftc.net 1171577255 Q * daniel_hozac saturn.oftc.net osmotic.oftc.net 1171577255 Q * Vudu saturn.oftc.net osmotic.oftc.net 1171577255 Q * UukGoblin saturn.oftc.net osmotic.oftc.net 1171577255 Q * Roey saturn.oftc.net osmotic.oftc.net 1171577255 Q * FaUl saturn.oftc.net osmotic.oftc.net 1171577255 Q * phedny saturn.oftc.net osmotic.oftc.net 1171577255 Q * neuralis saturn.oftc.net osmotic.oftc.net 1171577255 Q * micah saturn.oftc.net osmotic.oftc.net 1171577255 Q * cohan_ saturn.oftc.net osmotic.oftc.net 1171577255 Q * sc0tt saturn.oftc.net osmotic.oftc.net 1171577255 Q * ex saturn.oftc.net osmotic.oftc.net 1171577255 Q * vasko saturn.oftc.net osmotic.oftc.net 1171577255 Q * harry saturn.oftc.net osmotic.oftc.net 1171577255 Q * tamitall saturn.oftc.net osmotic.oftc.net 1171577255 Q * bogus saturn.oftc.net osmotic.oftc.net 1171577255 Q * Bertl saturn.oftc.net osmotic.oftc.net 1171577255 Q * FloodServ saturn.oftc.net osmotic.oftc.net 1171577275 J * olivierk_ ~olivier@olivierk.org 1171577275 J * meebey meebey@booster.qnetp.net 1171577275 J * DreamerC_ ~dreamerc@125-225-101-208.dynamic.hinet.net 1171577275 J * dlezcano ~dlezcano@AToulouse-252-1-54-66.w83-200.abo.wanadoo.fr 1171577275 J * fb_ fback@red.fback.net 1171577275 J * gerrit ~gerrit@mobile-166-214-051-125.mycingular.net 1171577275 J * marcfiu ~mef@aegis.CS.Princeton.EDU 1171577275 J * stefani ~stefani@flute.radonc.washington.edu 1171577275 J * bronson ~bronson@adsl-75-36-145-145.dsl.pltn13.sbcglobal.net 1171577275 J * meandtheshell ~markus@85-125-230-203.dynamic.xdsl-line.inode.at 1171577275 J * [PUPPETS]Gonzo gonzo@langweiligneutral.deswahnsinns.de 1171577275 J * infowolfe_ ~infowolfe@c-67-164-195-129.hsd1.ut.comcast.net 1171577275 J * CHTEKK ~chtekk@62.48.110.172 1171577275 J * cdrx ~legoater@cap31-3-82-227-199-249.fbx.proxad.net 1171577275 J * shedi ~siggi@ftth-237-144.hive.is 1171577275 J * pstader ~phil@pD95041DD.dip0.t-ipconnect.de 1171577275 J * sladen paul@starsky.19inch.net 1171577275 J * sannes ace@har.sagt.no 1171577275 J * dna_ ~naucki@240-219-dsl.kielnet.net 1171577275 J * mjt ~mjt@nat.corpit.ru 1171577275 J * brcc bruce@i.am.someasshole.com 1171577275 J * cehteh ~ct@pipapo.org 1171577275 J * michal` ~michal@www.rsbac.org 1171577275 J * bonbons ~bonbons@83.222.38.237 1171577275 J * comfrey_ ~comfrey@70.91.185.84 1171577275 J * comfrey ~comfrey@70.91.185.84 1171577275 J * Loki|muh loki@satanix.de 1171577275 J * s0undt3ch ~s0undt3ch@80.69.34.154 1171577275 J * DoberMann[PullA] ~james@86.196.164.254 1171577275 J * Guy- 55beZiFNRs@chardonnay.math.bme.hu 1171577275 J * SNy d450e9923a@bmx-chemnitz.de 1171577275 J * ensc ~irc-ensc@p54B4D2AE.dip.t-dialin.net 1171577275 J * mnemoc ~amery@kilo105.server4you.de 1171577275 J * rob-84x^ ~rob@submarine.ath.cx 1171577275 J * fs fs@213.178.77.98 1171577275 J * m`m`h ~simba@deb30.mgts.by 1171577275 J * ntrs ~ntrs@68-188-55-120.dhcp.stls.mo.charter.com 1171577275 J * rw23 squid@wwwbox.uni-mb.si 1171577275 J * hardwire ~hardwire@rdbck-5111.wasilla.mtaonline.net 1171577275 J * bj_ ~bj@insanefactory.com 1171577275 J * puck ~puck@leibniz.catalyst.net.nz 1171577275 J * ruskie ruskie@ruskie.user.oftc.net 1171577275 J * baldy baldy@baldy.biz 1171577275 J * Johnnie ~jdlewis@jdlewis.org 1171577275 J * eyck eyck@kuszelas.com 1171577275 J * matti matti@acrux.romke.net 1171577275 J * Adrinael_ adrinael@st12-127.tky.hut.fi 1171577275 J * blizz_ ~blizz@evilhackerdu.de 1171577275 J * Hollow ~hollow@styx.xnull.de 1171577275 J * sid3windr luser@bastard-operator.from-hell.be 1171577275 J * derjohn ~derjohn@80.69.41.2 1171577275 J * weasel weasel@weasel.noc.oftc.net 1171577275 J * nou Chaton@causse.larzac.fr.eu.org 1171577275 J * nox ~nox@nox.user.oftc.net 1171577275 J * Hunger Hunger.hu@Hunger.hu 1171577275 J * nebuchadnezzar ~nebu@zion.asgardr.info 1171577275 J * ard ~ard@82-197-200-127.dsl.cambrium.nl 1171577275 J * waldi ~waldi@bblank.thinkmo.de 1171577275 J * pusling pusling@195.215.29.124 1171577275 J * yang ~yang@yang.sponsor.oftc.net 1171577275 J * click click@ti511110a080-0186.bb.online.no 1171577275 J * Medivh ck@paradise.by.the.dashboardlight.de 1171577275 J * fosco fosco@konoha.devnullteam.org 1171577275 J * phreak`` ~phreak``@deimos.barfoo.org 1171577275 J * kaner kaner@strace.org 1171577275 J * mountie ~mountie@CPE0080c6fe323f-CM000a739acaa4.cpe.net.cable.rogers.com 1171577275 J * TrueBrain truelight@openttd.org 1171577275 J * mcp ~hightower@wolk-project.de 1171577275 J * Radiance 9510b0b257@halt.1984world.eu 1171577275 J * Wonka produziert@chaos.in-kiel.de 1171577275 J * badari ~badari@bi01p1.co.us.ibm.com 1171577275 J * Greek0 ~greek0@85.255.145.201 1171577275 J * tokkee tokkee@casella.verplant.org 1171577275 J * tamitall ~tam@gw.nettam.com 1171577275 J * neuralis ~krstic@solarsail.hcs.harvard.edu 1171577275 J * FaUl immo@shell.chaostreff-dortmund.de 1171577275 J * Roey ~katz@h-69-3-4-130.mclnva23.covad.net 1171577275 J * doener ~doener@host.magicwars.de 1171577275 J * UukGoblin ~jaaa@sr-fw1.router.uk.clara.net 1171577275 J * micah ~micah@micah.riseup.net 1171577275 J * harry ~harry@d54C2508C.access.telenet.be 1171577275 J * vasko ~vasko@unreal.rainside.sk 1171577275 J * bon` bon@stichting-brein.eu 1171577275 J * ex ex@valis.net.pl 1171577275 J * Vudu 35d83f8466@217.20.138.14 1171577275 J * morfoh ~morfoh@kilo105.server4you.de 1171577275 J * Bertl herbert@IRC.13thfloor.at 1171577275 J * sc0tt ~scott@209.51.169.84 1171577275 J * cohan_ ~cohan@koniczek.de 1171577275 J * phedny ~mark@phedny.vps.van-cuijk.nl 1171577275 J * glut glut@no.suid.pl 1171577275 J * daniel_hozac ~daniel@c-2c1472d5.010-230-73746f22.cust.bredbandsbolaget.se 1171577275 J * FloodServ services@services.oftc.net 1171577275 J * bogus ~bogusano@fengor.net 1171577560 Q * dna_ Quit: Verlassend 1171577617 M * marcfiu hello 1171577634 M * Bertl hey marcfiu! 1171577654 Q * marcfiu Quit: Download Gaim: http://gaim.sourceforge.net/ 1171577668 M * Bertl hmm ... 1171577669 J * marcfiu ~mef@aegis.CS.Princeton.EDU 1171577673 M * Bertl wb marcfiu! 1171577674 M * marcfiu hello Bertl 1171577684 M * Hollow Bertl: btw, can we get a *at() version of the ix_attr_set syscall? 1171577711 M * Bertl ix_attr_set? 1171577728 M * Hollow ehm.. iattr_set is the vcmd iirc :) 1171577751 M * Bertl basically np, but what for? 1171577819 M * Hollow would save us quite a lot of string overhead during creation of guests.. we use nftw and have to build a path from vdir and the relative path inside the template to be able to set iattr on files in the new guest 1171577846 M * Hollow i hope you understood it :) 1171577969 Q * meandtheshell Quit: Leaving. 1171577971 M * Hollow basically the do_chxid block in http://svn.linux-vserver.org/projects/vcd/browser/trunk/src/vcd/methods/vx/vx_create.c#L197 1171578453 J * Aiken ~james@ppp109-15.lns2.bne4.internode.on.net 1171578521 M * Bertl welcome Aiken! 1171578549 M * Bertl Hollow: okay, have to look into how we integrate that into the switch 1171578574 M * Hollow Bertl: ok, thanks 1171578708 P * stefani I'm Parting (the water) 1171578781 M * Bertl Hollow: you probably want that for the get_iattr too? 1171578863 M * Hollow Bertl: well, we don't need it now.. 1171578872 M * Hollow but it shouldn't hurt i guess :) 1171578926 M * Bertl now, the interesting question is, you probably want that in 2.2.0, yes? 1171578952 M * Hollow if possible, yes 1171578963 M * Bertl means you have to test it a little ... 1171578969 M * Hollow sure, no problem 1171579027 M * Bertl hmm ... 1171579046 M * Bertl we have the xid in the struct already 1171579086 M * Bertl that means we do not use the id argument 1171579213 M * Bertl i.e. we can use that one for the file descriptor 1171579227 M * Hollow Bertl: apropos.. did i interpret the source right: you can only set one dlimit per superblock (i.e. filesystem) per xid? 1171579236 M * Hollow yup, sounds like a plan 1171579239 J * eyck_ eyck@kuszelas.com 1171579249 M * Bertl one dlimit per tuple (superblock, xid) 1171579260 Q * eyck Read error: Connection reset by peer 1171579267 M * Hollow yep 1171579291 M * Hollow we were confused by the path argument in the struct .. 1171579300 M * Hollow and tried to set different limits on different paths 1171579356 M * Bertl ah, like bind mounts or so? 1171579378 M * CHTEKK no, we thought you maybe could set a limit for /vserver/bla/var and another for /vserver/bla/usr 1171579382 N * DoberMann[PullA] DoberMann 1171579384 M * CHTEKK and that wasn't the case :) 1171579387 M * Hollow no, just on different directories on the same filesystem 1171579644 M * Bertl ah, well, that is a problem because of the way how unix filesystems work 1171579659 M * Bertl many folks tried directory based approaches, but almost all of them failed 1171579781 M * Bertl daniel_hozac: what do the various util-vserver APIs pass as id when calling vc_get/set_iattr 1171579790 M * Bertl + 1171579792 M * Bertl ? 1171579938 M * Hollow Bertl: sure, it is no problem at all, we just figured out how the interface works by trail & error until i looked at the source ;) 1171579967 M * Bertl yeah, never look at the source too soon ... spoils all the fun :) 1171579974 M * CHTEKK indeed :D 1171579976 M * Hollow heh 1171579994 M * Hollow at least good for testing the error cases :) 1171580004 M * CHTEKK getting all the cool "file already exists" error, and the totally "eehh wtf?" expression that comes over you at that moment, that's 70% of the fun :) 1171580088 J * xe ex@81.219.196.129 1171580177 Q * xe 1171580367 M * Hollow Bertl: util-vserver currently passes 0 as id 1171580493 P * marcfiu 1171580495 M * Hollow maybe we can enable the at() behaviour with a flag and use id for the fd? 1171580517 M * Bertl yes, that was my idea 1171580533 M * Bertl do we know the 0 id for older (legacy stuff) too? 1171580561 M * Hollow i'm not completely sure what the fscompat api does .. 1171580604 M * Bertl because I guess we can make that exception that 0 is not allowed as filedesciptor 1171580621 M * Bertl it's a little untypical, but I guess it won't hurt real world setups 1171580653 M * Hollow will fd 0 be reused once it is closed but fds > 0 still exist? 1171580661 M * Bertl yes 1171580726 M * Hollow well, the daemon closes std fds on startup, so there might be a chance that fd 0 will be reused.. threfore the idea with the flag to be sure no legacy code accidently calls the at() version 1171580807 M * Bertl the thing is, we have to mask out the flag 1171580820 M * Bertl which will in turn block this specific flag value 1171580880 M * Bertl but yes, we can do that and probably it's the better choice 1171580912 M * Bertl #define IATTR_AT 0x10000000 1171580919 M * Bertl something like that? 1171580960 M * Hollow yep, sounds good 1171581020 Q * gerrit Ping timeout: 480 seconds 1171581049 M * Bertl now, that leaves another util-vserver question 1171581066 M * Bertl is the flag/mask value set to zero on get_iattr? 1171581113 M * Hollow Bertl: well, it is not initialized at all... 1171581236 M * Bertl hmm .. that might be a problem then 1171581261 M * Hollow yeah 1171581282 Q * Aiken Quit: Leaving 1171581294 N * DoberMann DoberMann[ZZZzzz] 1171581356 M * Hollow Bertl: well, after some optimizations the string functions don't use too many instructions anymore.. maybe it would be too much overkill 1171581383 M * Hollow (the at() version for iattr i mean) 1171581396 M * Bertl okay, so we keep that as idea for a later time ... 1171581417 Q * bonbons Quit: Leaving 1171581423 M * Hollow yeah, we see how it will perform, but it already is quite fast :) 1171581449 M * Hollow creating a new guest typically takes 1-2 seconds now 1171581463 M * CHTEKK you tried that on a normal system Hollow ? 1171581465 M * Hollow (at least on the quad :) 1171581474 M * Hollow no, but i will 1171581518 M * CHTEKK :) it's not much the quad there that speeds creation up I'd say, but the 8 disk hardware sata2 raid behind it, and the gigs of ram that keep the stuff in cache 1171581533 M * CHTEKK actually the whole stage4 fits just in the hardware-raid controller's onboard ram :P 1171581544 M * Hollow lol 1171581566 M * CHTEKK 256mb are on the controller for cached operations, and the stage4 is, unpacked, about 220 mb 1171581773 J * Aiken ~james@ppp109-15.lns2.bne4.internode.on.net 1171581885 Q * Aiken 1171582005 Q * ensc Ping timeout: 480 seconds 1171582530 M * Hollow off to bed now, cu tomorrow 1171582583 M * CHTEKK gn8 Hollow 1171582605 M * Bertl cya 1171583263 Q * DreamerC_ Quit: leaving 1171583296 J * DreamerC ~dreamerc@125-225-101-208.dynamic.hinet.net