1317340855 M * Rockj ohh Bertl 1317340875 M * Rockj probably my server has issue because I always have compiled my own kernel on it and not used the default one in the debian repositories 1317340882 M * Rockj anyhow, it probably is an issue in the debian unstable 1317340885 M * Rockj I would guess? 1317340887 M * Rockj :) 1317340973 M * Bertl hmm? 1317340999 M * Bertl what issue are we talking about? 1317341013 M * Rockj the nfs one 1317341046 M * Bertl well, that one clearly was a bug in the kernel, and we fixed it, no? 1317341055 M * Rockj true. 1317341059 M * Rockj :) 1317342080 Q * dowdle Remote host closed the connection 1317350182 J * clopez ~clopez@238.10.117.91.dynamic.mundo-r.com 1317352502 Q * clopez Ping timeout: 480 seconds 1317354119 J * clopez ~clopez@238.10.117.91.dynamic.mundo-r.com 1317354885 Q * clopez Ping timeout: 480 seconds 1317356969 J * sannes ~ace@cm-84.209.106.118.getinternet.no 1317360256 Q * transacid Remote host closed the connection 1317360589 J * fisted_ ~fisted@xdsl-87-78-210-201.netcologne.de 1317360778 Q * fisted Ping timeout: 480 seconds 1317362163 M * Bertl off to bed now ... have a good one everyone! 1317362177 N * Bertl Bertl_zZ 1317362522 J * ncopa ~ncopa@3.203.202.84.customer.cdi.no 1317364896 J * Aiken_ ~Aiken@2001:44b8:2168:1000:21f:d0ff:fed6:d63f 1317364896 Q * Aiken Read error: Connection reset by peer 1317366466 J * ghislain ~AQUEOS@adsl2.aqueos.com 1317369364 M * daniel_hozac Bertl_zZ: hmm, the keyring thing is just a warning for me. 1317369413 M * daniel_hozac Bertl_zZ: could you paste your command and output when you wake up? 1317369576 J * emilio49 ~emilio49@9YYAABUAG.tor-irc.dnsbl.oftc.net 1317369786 P * emilio49 1317370993 Q * ntrs Ping timeout: 480 seconds 1317371488 J * ntrs ~ntrs@vault08.rosehosting.com 1317378106 Q * micah Remote host closed the connection 1317378429 J * micah ~micah@micah.riseup.net 1317379432 N * Bertl_zZ Bertl 1317379436 M * Bertl morning folks! 1317379501 M * Bertl daniel_hozac: sure, the guest was built with: 1317379528 M * Bertl vserver vps50 build -m debootstrap --context 50 --hostname vps50.kunden-server.org --interface eth0:46.4.153.22/32 -- -d squeeze -m ftp://ftp.freenet.de/debian -- --arch amd64 1317379546 M * Bertl (that succeeded after installing the gpg key) 1317379599 M * Bertl and this is what I get when I try to start it: 1317379603 M * Bertl http://paste.linux-vserver.org/20615 1317379622 M * daniel_hozac how about the build? 1317379629 M * daniel_hozac i.e. when the keyring failed you 1317379665 M * daniel_hozac the start is expected, i missed a sed :) 1317379697 M * daniel_hozac http://git.linux-vserver.org/cgi-bin/gitweb.cgi?p=util-vserver.git;a=commitdiff;h=2e45bc70c885e5e7be29206330eb45e53a741c90 should fix that. 1317379714 M * Bertl http://paste.linux-vserver.org/20616 1317379720 M * Bertl that was the build 1317379758 M * Bertl ah, you want the one where the keyring was missing, sec 1317379844 M * Bertl that was "my" fault, because I forgot to set the --arch 1317379859 M * daniel_hozac hehe 1317379860 M * daniel_hozac okay. 1317379862 M * Bertl i.e. the keyring seems to have been reported as 'W' as you said 1317379872 M * Bertl while it fails on the next line with: 1317379884 M * Bertl E: Invalid Release file, no entry for main/binary-x86_64/Packages 1317379888 M * daniel_hozac right 1317380006 M * daniel_hozac i'm just gonna fix that while i'm at it. 1317380070 M * Bertl I can confirm, with the diff, the guest starts fine 1317380081 M * daniel_hozac great 1317380104 M * daniel_hozac my testsetup is currently under reconstruction... 1317380150 M * Bertl hehe, been there too ... 1317380280 M * daniel_hozac so 2994 should fix those issues... 1317380299 M * daniel_hozac but uploading that will have to wait a few hours. 1317380301 M * Bertl btw, did you see the nfs bug which seems to have gone (almost) unnoticed since quite a while? 1317380313 M * daniel_hozac yeah, interesting for sure. 1317380328 M * Bertl I obviously got confused with INOTAG vs TAGINO 1317380336 M * daniel_hozac heh 1317380352 M * Bertl should have named them differently I guess 1317380366 M * Bertl something like MapInodeToTag :) 1317380422 M * daniel_hozac hehe 1317380479 M * daniel_hozac each line would need several linewraps to fit in the 80 chars. 1317380628 M * Bertl something completely different: do you, or anybody else here, know a way to overwrite/fix "Currently unreadable (pending) sectors" which are also "Offline uncorrectable sectors" without booting into DOS and running DLGDIAG on WD disks? 1317380698 M * Bertl it seems it works to 'just' overwrite the sector if you know which one, but testing with badblocks for example yields a perfectly working device ... so no luck there 1317381366 M * fback Bertl: this shouldn't be doable without special tools 1317381393 M * fback (and maybe dlgdiag is such a tool, don't know) 1317381446 M * Bertl what I do not understand is that the disk does not remap the pending sector on offline/long tests 1317381447 M * fback bad sectors should be automagically relocated to spare, and addressing such sector points to a new location afterwards 1317381463 M * fback maybe it's out of them? 1317381483 M * Bertl no, not really, there is a separate attribute for that 1317381520 M * Bertl 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0 1317381545 M * Bertl 196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0 1317381624 M * Bertl so I have no clue why there is still a pending/offline uncorr. sector despite the fact that the entire (reachable) disk can be read without error 1317381719 M * Bertl my best explanation so far is that the sector is in the spare area itself 1317381746 M * Bertl (or a bug in that disk's firmware :) 1317383121 M * fback Bertl: hm, sectors in spare are possibly equally to fail with any other sectors, but not considering it would be strange 1317383184 M * fback Bertl: otoh, seeing failing sectors should be the mark to replace the drive, not to hunt for them :) 1317383208 M * Bertl well, yeah, the problem is, WD thinks differently about that 1317383238 M * Bertl and I can understand that a single bad sector/remapping is quite fine for a 3TB disk 1317383243 J * clopez ~clopez@238.10.117.91.dynamic.mundo-r.com 1317383264 M * Bertl i.e. there are probably dozens of bad sectors when the drive is first tested (you'll never know about) 1317383537 M * fback Bertl: what worries me always with sector relocations, old data is left in "bad" sector probably 1317383569 M * fback with 3TB drive there's little probability it's something sensitive, but it's still there 1317383593 M * Bertl well, I'm not worried about that 1317383658 M * Bertl (I'd never let sensitive data hit a disk unencrypted :) 1317383795 M * fback swap? 1317383803 M * Bertl nope 1317383845 Q * Aiken_ Remote host closed the connection 1317383849 M * Bertl swap (if any) is on encrypted ssd, for several reasons 1317387468 M * meebey Bertl: hey, which patch should I apply now for the nfs uid/gid issue fix01 and 02 or just 02? 1317387504 M * Bertl well, 02 is the relevant one, but 01 IMHO isn't wrong either 1317387545 M * meebey does 01 fix other scenerios? 1317387575 M * Bertl yes, but they are unlikely to occur 1317387593 M * meebey ok 1317387605 M * meebey I will try 02 then as debian has strong backport policies 1317387712 Q * clopez Ping timeout: 480 seconds 1317387914 M * Bertl not quite unexpected ... anyway, need a nap now ... bbl 1317387927 N * Bertl Bertl_zZ 1317387966 M * meebey http://paste.debian.net/133212/ 1317387993 M * daniel_hozac Bertl_zZ: IIRC you have to write to the drive for them to be replaced. 1317390081 M * meebey CC [M] fs/nfs/inode.o 1317390082 M * meebey LD [M] fs/nfs/nfs.o 1317390087 M * meebey sounds promising, without full rebuild 1317391301 Q * pmjdebru1jn Quit: leaving 1317392608 J * pmjdebruijn ~pascal@overlord.pcode.nl 1317392669 M * meebey yay, the nfs4 uid/gid crisis is over! \o/ 1317392684 Q * pmjdebruijn 1317392699 J * pmjdebruijn ~pascal@overlord.pcode.nl 1317392757 M * meebey Bertl_zZ: delta-nfs-fix02.diff fixed it for me, nfs client on host with vserver patch 1317392760 Q * quasisane Quit: leaving 1317393906 Q * ncopa Quit: Leaving 1317395139 J * dowdle ~dowdle@scott.coe.montana.edu 1317395520 N * Bertl_zZ Bertl 1317395525 M * Bertl back now ... 1317395536 M * Bertl daniel_hozac: yeah, I'm just not sure how to do that :) 1317395561 M * Bertl meebey: great! please update the debian bugtracker/etc 1317395573 M * meebey Bertl: will do 1317395849 M * daniel_hozac Bertl: fd = open('/dev/sdXY', O_RDWR|O_DIRECT); while ((x = read(fd, buf, sizeof(buf)) != -1) { writeall(fd, buf, x); } ? :) 1317395861 M * daniel_hozac well, with a seek in there. 1317395909 M * daniel_hozac maybe even dd if=/dev/sdXY of=/dev/sdXY bs=1M would work... 1317395984 M * Bertl so you think it is one of the readable blocks? hmm 1317396020 M * Bertl not sure why a readable block would be classified as offline uncorrectable though, and why it wouldn't get remapped by the offline tests? 1317396126 M * daniel_hozac although i suppose you could run KVM and give it access to your disk 1317396130 M * daniel_hozac with DOS 1317396195 M * Bertl yeah, actually thought about that as well, besides, it's not that hard to put that disk in a separate network bootable system and boot DOS via pxe 1317396207 M * daniel_hozac right 1317396213 M * Bertl I was more looking for a way to handle such cases in a running system 1317396488 Q * ntrs Ping timeout: 480 seconds 1317396809 M * Bertl thing is, I have deployed a raid system which does a lot of self testing and data integrity checks, including regular raid disk scrubbing and close smart monitoring ... now I have one disk (out of 12) which reports this offline uncorrectable error while all scrubbing (check/repair) on the raid says everything is fine 1317396916 M * Bertl usually (and it seems that with WD disks that's quite common) a pending sector means that there was a read error which got reported to the upper layer, the disk will check more closely when doing offline tests 1317396918 J * ntrs ~ntrs@vault08.rosehosting.com 1317396952 M * Bertl the next level is that a pending sector becomes an offline uncorrectable sector (that is when the offline tests couldn't read and reallocate it either) 1317397016 M * Bertl in that case, usually the next raid scrubbing hits that sector, the soft raid notices the read error, regenerates the data from the remaining disks and rewrites the sector, which in turn leads to the pending sector becomming relocated 1317397045 M * Bertl and after the next offline check, the offline uncorrectable sector is gone as well, as it was remapped by the write 1317397084 M * Bertl of course, that never happens when the drive can read each and every sector accessible :) 1317397178 M * Bertl I can (and might) retrigger a complete raid rebuild on that disk, just to see if that sector is hidden somewhere and not properly reported or if it is outside the accessible range (or simply a bug in the firmware accounting) 1317397216 J * ensc|w ~ensc@www.sigma-chemnitz.de 1317397263 M * Bertl the really funny part is, I really suspect an accounting bug in the firmware, as the extended offline test completes without error 1317397348 M * Bertl but enough on (luckily) cheap multi TB sata disks :) 1317402037 J * Walex ~Walex@87-194-99-40.bethere.co.uk 1317406054 J * fisted ~fisted@xdsl-87-78-215-35.netcologne.de 1317406083 Q * fisted_ Ping timeout: 480 seconds 1317410582 Q * hparker Quit: Quit 1317410935 J * bonbons ~bonbons@2001:960:7ab:0:b8dd:43e9:9f4a:350b 1317411681 Q * FireEgl Remote host closed the connection 1317412384 J * petzsch ~markus@p57B66E20.dip.t-dialin.net 1317412599 Q * ntrs Ping timeout: 480 seconds 1317412641 J * FireEgl FireEgl@2001:470:e056:1:d51d:4802:c7b5:b6c2 1317413043 J * ntrs ~ntrs@vault08.rosehosting.com 1317413246 M * petzsch good evening :) 1317414011 J * Aiken ~Aiken@2001:44b8:2168:1000:21f:d0ff:fed6:d63f 1317414037 Q * Aiken 1317415407 Q * sannes Remote host closed the connection 1317415841 J * Aiken ~Aiken@2001:44b8:2168:1000:21f:d0ff:fed6:d63f 1317416314 J * mib_8ff5og 51db567c@ircip1.mibbit.com 1317416342 Q * petzsch Quit: good night 1317416483 M * mib_8ff5og is any easy way to install vserver on ubuntu 11.04 ? There is no linux-vserver in repositories. Is the only way to compile it ? 1317417373 M * Bertl well, compiling is the easy way, but you can as well use one of the broken debian packages 1317419730 Q * mib_8ff5og Quit: http://www.mibbit.com ajax IRC Client 1317423423 Q * bonbons Quit: Leaving 1317426512 Q * guerby Ping timeout: 480 seconds 1317426715 Q * Walex Remote host closed the connection