reiserfsck --rebuild-tree bug (loops forever)
Hi, I got a filesystem on a 75 GB disk that is damaged. Reiserfsck asked me to run --rebuild-tree on it, and so I did. However it never finishes. Unfortunately I don't have the log for the original --rebuild-tree run. This is the log for the third run: ### Pass 0 ### pass0: vpf-10170: block 70127: item 4: Wrong order of items - the item 1109346 1109220 0x21 DRCT (2), len 1352, location 2568 entry count 65535, fsck need 1, format new fixed to 1109346 1109220 0x1 DRCT (2), len 1352, location 2568 entry count 65535, fsck need 1, format new pass0: vpf-10170: block 810276: item 3: Wrong order of items - the item 1351778 1774183 0x401 DRCT (2), len 1320, location 720 entry count 65535, fsck need 1, format new fixed to 1351778 1774183 0x1 DRCT (2), len 1320, location 720 entry count 65535, fsck need 1, format new pass0: vpf-10170: block 1581992: item 30: Wrong order of items - the item 322991 1592495 0x81 DRCT (2), len 8, location 1224 entry count 65535, fsck need 1, format new fixed to 322991 1592495 0x1 DRCT (2), len 8, location 1224 entry count 65535, fsck need 1, format new pass0: vpf-10170: block 1582012: item 1: Wrong order of items - the item 348331 348342 0x3a9 DRCT (2), len 424, location 3628 entry count 65535, fsck need 1, format new fixed to 348331 348342 0x1 DRCT (2), len 424, location 3628 entry count 65535, fsck need 1, format new pass0: vpf-10170: block 1600587: item 2: Wrong order of items - the item 4081 509323 0x189 DRCT (2), len 280, location 3728 entry count 65535, fsck need 1, format new fixed to 4081 509323 0x1 DRCT (2), len 280, location 3728 entry count 65535, fsck need 1, format new pass0: vpf-10170: block 1633224: item 1: Wrong order of items - the item 77103 1029558 0x669 DRCT (2), len 1888, location 2164 entry count 65535, fsck need 1, format new fixed to 77103 1029558 0x1 DRCT (2), len 1888, location 2164 entry count 65535, fsck need 1, format new pass0: vpf-10160: block 1759233: item 8: No "." entry found in the first item of a directory pass0: vpf-10170: block 1876180: item 1: Wrong order of items - the item 960509 1130326 0x441 DRCT (2), len 1560, location 2492 entry count 65535, fsck need 1, format new fixed to 960509 1130326 0x1 DRCT (2), len 1560, location 2492 entry count 65535, fsck need 1, format new pass0: vpf-10160: block 4090916: item 5: No "." entry found in the first item of a directory pass0: vpf-10170: block 14327865: item 1: Wrong order of items - the item 960509 1338428 0x111 DRCT (2), len 2976, location 1076 entry count 65535, fsck need 1, format new fixed to 960509 1338428 0x1 DRCT (2), len 2976, location 1076 entry count 65535, fsck need 1, format new pass0: vpf-10170: block 14847200: item 5: Wrong order of items - the item 1084523 1084578 0x659 DRCT (2), len 552, location 1148 entry count 65535, fsck need 1, format new fixed to 1084523 1084578 0x1 DRCT (2), len 552, location 1148 entry count 65535, fsck need 1, format new 1068939 directory entries were hashed with "r5" hash. ### Pass 1 ### ### Pass 2 ### do_pass_2: The block (18767039) is in the tree already. Should not happen. do_pass_2: The block (18767039) is in the tree already. Should not happen. do_pass_2: The block (18767039) is in the tree already. Should not happen. It loops forever at this point, using up 100% cpu time. dawn:~# reiserfsck -VI got a full backup of the original filesystem made with 'dd'. It is not in a worse state that I can access most of it. It seems however that reiserfsck is unable to fix the errors in it? -- Baldur Norddahl <[EMAIL PROTECTED]>
Re: reiserfsck --rebuild-tree bug (loops forever)
Hi, 3.6.4 is not the latest reiserfsck version. 3.6.5 [1] is the latest and several bugs have been fixed since. Could you please retry with reiserfsck 3.6.5 ? Thanks, Philippe [1] Reiserfprogs : ftp://ftp.namesys.com/pub/reiserfsprogs/reiserfsprogs-3.6.5.tar.gz On 21 Mar 2003 10:31:24 +0100 Baldur Norddahl <[EMAIL PROTECTED]> wrote: | dawn:~# reiserfsck -V |
Re: reiserfsck --rebuild-tree bug (loops forever)
Hello! On Fri, Mar 21, 2003 at 10:31:24AM +0100, Baldur Norddahl wrote: > ### Pass 2 ### > do_pass_2: The block (18767039) is in the tree already. Should not > happen. > do_pass_2: The block (18767039) is in the tree already. Should not > happen. > do_pass_2: The block (18767039) is in the tree already. Should not > happen. > It loops forever at this point, using up 100% cpu time. Hm, all previous reports of this problem boiled down to a situation where people build their reiserfsprogs on one box, but used it on another. Perhaps try to build reiserfsck statically? (and use 3.6.5 of course). Bye, Oleg
Re: filesystem corruption ?
On Friday 21 March 2003 08:32, you wrote: > Hello! > > On Thu, Mar 20, 2003 at 07:23:48PM +0100, Bernd Schubert wrote: > > > Hm, interesting. > > > And what are the differences? How big are they? > > > > Since it are binaries files, a colleague had the idea to use hexdump and > > diff, so the command for the attached file was: > > diff <(hexdump /worka/gdb) <(hexdump /usr/bin/gdb)|sort -k 2 >gdb.diff > > So the lines beginning with '<' are from working gdb and lines beginning > > with '>' are from corrupted gdb. When you look into the diff-file you > > will see, that only some bits per line have changed. > > I see. > Basically you have two pages of data corrupted. > And the corruption indeed looks like bit corruption. > How about rebooting that box and checking if corruption pattern changes? > Also I'd recommend you to run memtext86 for some time as this looks like > bad memory pattern. All of our machines have to pass a full memtest86 checking before we intend to use them - this machine is about 3 weeks old, of course it also had to run this test and furthermore it has ECC-memory. > > > > Any events happening between morning backup and time of problem > > > discovery? > > > > Except, that I recompiled a kernel and we installed some programs using > > aptitude (its a debian system), nothing happend to the filesystem. There > > was also no reboot, no crash, etc. > > Update: The corruption probably happend at 15:48, since at this time also > > a xchat on one of the clients crashed and this was noticed by us at > > first. The xchat binary was also affected by the corruption. > > So, the beam of X-rays run through the memory module corrupting some bits? There is the 'Environmental Physics Institut' in the floor below us and since we currently have an extremely high hardware failure rate, I have been joking for some time that they might be causing it (I believe they are indeed using x-ray beams). I should really ask them if their constructions are shielded properly ;-) > ;) This stuff should not have been written to disk, so probably > plain reboot should fix everything? Can you test that? Yes of course, if something goes wrong we still have our fall back machine :-) I will report in the afternoon if it worked. Best regards, Bernd
Re: filesystem corruption ?
Hi, > So, the beam of X-rays run through the memory module corrupting some bits? > ;) This stuff should not have been written to disk, so probably > plain reboot should fix everything? Can you test that? > indeed after rebooting everything is fine again. We will run another memtest86 during the weekend, though I really don't believe we will find a problem. Though this machine will be replaced by a real server in a few month, I'm still rather worried what happend. Even if its 'only' a hardware memory problem this means lots of trouble for us -- on the one hand it seems not to be memtest86 detectable and on the other hand our programs really do need working memory, but of course this is not of your concern. Thanks for your help, Bernd
Re: filesystem corruption ?
Hello! On Fri, Mar 21, 2003 at 02:01:38PM +0100, Bernd Schubert wrote: > > So, the beam of X-rays run through the memory module corrupting some bits? > > ;) This stuff should not have been written to disk, so probably > > plain reboot should fix everything? Can you test that? > indeed after rebooting everything is fine again. We will run another memtest86 So on-disk corruption is out of question. > during the weekend, though I really don't believe we will find a problem. Ask those physics guys to run some X-ray experiments while you are running memtest86 ;) > Though this machine will be replaced by a real server in a few month, I'm > still rather worried what happend. Even if its 'only' a hardware memory > problem this means lots of trouble for us -- on the one hand it seems not to > be memtest86 detectable and on the other hand our programs really do need Well, it may be not detectable because no high-enerty beams are running around at the time of test. > working memory, but of course this is not of your concern. I've learn in the school that if you put some bit amount of plumbum in between some area and source of radiation, chances are radiation that will reach the protected area will be of much lesser strenght. In fact you might go to those guys and ask them what matherial (and how much of it) is best suited to shield against stuff they generate. Bye, Oleg
Re: reiserfsck --rebuild-tree bug (loops forever)
Hi, 3.6.5 asked me to run --rebuild-sb and then --rebuild-tree. That worked, and the filesystem is repaired. Oleg Drokin suggested that I might be running a version that was not compiled on the same server. I was actually using the version that debian provided for me. The namesys.com web site is still advertizing 3.6.4 as the latest version, maybe that should be corrected. Thanks, Baldur On Fri, 2003-03-21 at 10:37, Philippe Gramoullé wrote: > Hi, > > 3.6.4 is not the latest reiserfsck version. > > 3.6.5 [1] is the latest and several bugs have been fixed since. > > Could you please retry with reiserfsck 3.6.5 ? > > Thanks, > > Philippe > > [1] Reiserfprogs : ftp://ftp.namesys.com/pub/reiserfsprogs/reiserfsprogs-3.6.5.tar.gz > > > On 21 Mar 2003 10:31:24 +0100 > Baldur Norddahl <[EMAIL PROTECTED]> wrote: > > | dawn:~# reiserfsck -V > |-- Baldur Norddahl <[EMAIL PROTECTED]>
Re: filesystem corruption ?
> I've learn in the school that if you put some bit amount of plumbum in > between some area and source of radiation, chances are radiation that will > reach the protected area will be of much lesser strenght. > In fact you might go to those guys and ask them what matherial (and how > much of it) is best suited to shield against stuff they generate. We already discussed during the lunch time to order somthing like this for our systems ;-) (would be a rather strange order for a usual computer company, wouldn't it ?) But in fact, I'm now really going to contact the those guys and ask if they have some stuff to detect their beams. Have a nice weekend, Bernd
[SPAM] 孤独是可耻，加入激情公社，告别单身
Start SpamAssassin results 18.40 points, 8 required; * 0.9 -- From: ends in numbers * 0.3 -- Message-Id has no @ sign * 1.0 -- BODY: Body includes 8 consecutive 8-bit characters * 4.0 -- BODY: Written in an undesired language * 1.0 -- BODY: Message is 60% to 70% HTML * 3.2 -- BODY: Character set indicates a foreign language * 0.3 -- BODY: HTML mail with non-white background * 0.3 -- BODY: HTML font color is red * 0.4 -- BODY: HTML font color is green * 0.0 -- BODY: HTML included in message * 0.2 -- BODY: JavaScript code * 0.4 -- BODY: Frontpage used to create the message * 0.2 -- BODY: Includes a URL link to send an email * 0.6 -- URI: Includes a link to a likely spammer email address * 2.1 -- A foreign language charset used in headers * 1.0 -- Forged mail pretending to be from MS Outlook * 1.0 -- Message only has text/html MIME parts * 1.0 -- From an address that is all numbers (non-phone) * 0.5 -- A foreign language charset used in HTML markup End of SpamAssassin results The original message did not contain plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor. --- Begin Message --- Title: 激情公社 首先，我要告诉你的是；而且你也一定要记住的是；再提醒一下，不要忘记哟：激情公社是目前国内领先的手机短信交友网站。 这里是所有短信主义分子，聚会主义分子，情感泛滥主义分子，小资情调主义分子及其它各类时尚族人的理想天地。如果你笃定自己是一个自信的人，一个不甘于吃饭工作睡觉这类简单生活的人，一个独步都市丛林、时刻守望狂野与激情的人。那么，加入这个百万社员的无线大聚会吧！请输入以下手机号马上开始 服务信箱：[EMAIL PROTECTED] GO一起上 版权所有 --- End Message ---
Re: filesystem corruption ?
On Fri, 21 Mar 2003 14:07, Oleg Drokin wrote: > I've learn in the school that if you put some bit amount of plumbum in It's better known in English as "lead". The problem with lead is that it's poisonous and soft. Having to wash your hands after touching your computer could get annoying. Other metals such as copper and steel will reduce the radiation and can also be used for protection against mechanical damage. The best way to reduce radiation is by distance. The inverse-square law applies, so moving the computer further away from the experiment will reduce the radiation more easily than anything else you may do. One thing to consider is disk-less X-term machines for if you need to operate a computer from near the experiment, so if the X-term crashed from radiation then your server with the data should continue running correctly. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
reiserfsck "block is in the tree already" error
I've been trying to rebuild the tree on a reiserfs partition that seems to have gotten corrupted during a resize operation. Unfortunately, I've gone from having one or two directories not accessible to having the whole partition not accessible now. Everything seems to go ok until pass 2. At this point I start getting this error: "do_pass_2: The block (4901823) is in the tree already. Should not happen." This keeps coming up as fast as the terminal will display it. It seems to be an endless loop as leaving it on for 4 hours resulted in an essentially infinite number of error messages with no corresponding disk activity. I'm running reiserfsck with the following command line: reiserfsck -z -S --rebuild-sb --rebuild-tree /dev/hda3 I'm pretty sure that -z and --rebuild-sb are more or less unnecessary, but I'm trying to be thorough. Running just reiserfsck --rebuild-tree /dev/hda3 results in a similar error message. I don't remember the exact wording of it, but it is along the lines of, "marked as a leaf but is not a leaf". Any suggestions are very welcome. I'd certainly hate to lose all of this data. p.s. My system is Debian GNU/Linux Unstable, running a 2.4.20 kernel. -- Alex Malinovich Support Free Software, delete your Windows partition TODAY! Encrypted mail preferred. You can get my public key from any of the pgp.net keyservers. Key ID: A6D24837 signature.asc Description: This is a digitally signed message part
Re: filesystem corruption ?
On Fri, 21 Mar 2003 17:00:09 +0100, Russell Coker said: > The problem with lead is that it's poisonous and soft. Having to wash your > hands after touching your computer could get annoying. Been there, done that. Had an experimental rig that for various reasons meant that we had a old AT-class computer that had to be within 4-6 inches of the beam in the accelerator (the actual constraint was a 18" tether one end of which was in a memory slot and other end which was actually in the beam). We had a lot of problems with backscattered stuff, so we ended up with a jacket that had a layer of lead to stop the high-energy stuff, but that had a lot of thermal neutrons coming out of it, so there was a layer of paraffin (I think, it's been close to 20 years now) to moderate those, and then the paraffin emitted the occasional alpha and beta particles, so there was a layer of metal foil to stop THOSE. If I got some more caffeine into me, I might even be able to relate the multiple layers needed for that rig to filesystem design. ;) pgp0.pgp Description: PGP signature
Re: reiserfsck "block is in the tree already" error
Hi, On Friday 21 March 2003 20:05, Alex Malinovich wrote: > I've been trying to rebuild the tree on a reiserfs partition that seems > to have gotten corrupted during a resize operation. Unfortunately, I've > gone from having one or two directories not accessible to having the > whole partition not accessible now. Everything seems to go ok until pass > 2. At this point I start getting this error: > > "do_pass_2: The block (4901823) is in the tree already. Should not > happen." It seems that reiserfsck was built on another computer, which has some other libs version, not statically. Would you try to rebuild it and try again. -- Thanks, Vitaly Fertman
[SPAM] ** You are approved.
Start SpamAssassin results 13.80 points, 8 required; * 1.0 -- Subject talks about being approved * 1.3 -- From: does not include a real name * 1.0 -- Bulk email software fingerprint (eGroups) found in headers * 1.4 -- BODY: Incorporates a tracking ID number * 0.0 -- BODY: HTML included in message * 1.0 -- BODY: Message is 40% to 50% HTML * 0.2 -- BODY: HTML font color is missing hash ( * 0.4 -- RAW: MIME section missing boundary * 1.4 -- RAW: Message text disguised using base-64 encoding * 0.6 -- URI: Uses %-escapes inside a URL's hostname * 1.0 -- URI: Completely unnecessary %-escapes inside a URL * 2.5 -- Date: is 24 to 48 hours after Received: date * 1.0 -- Message-Id is fake (in Outlook Express format) * 1.0 -- Message only has text/html MIME parts End of SpamAssassin results The original message did not contain plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor. --- Begin Message --- albumin , water-soluble blood protein Your home refinance loan is approved! To get your approved amount go here. To be excluded from further notices go here. albumin , water-soluble blood protein 1gate 8451KaEE0-223THUC8417XagP7-821YQee4045Vnyt3-248l44--- End Message ---
Re: datalogging and quota patches port to 2.4.21-pre6
On 03/20/2003 04:13 PM, Oleg Drokin wrote: Hello! Ok, so I ported Chris' patches to 2.4.21-pre6 (should appear on your kernel.org mirror soon, have appeared in bk already). Patches are at ftp://namesys.com/pub/reiserfs-for-2.4/testing/data-logging-and-quota-2.4.21-pre6 They are intend to replace similar named patches from Chris' ftp directory at ftp://ftp.suse.com/pub/people/mason/patches/data-logging/2.4.21 Also if you want to try these patches with 2.4.21-pre5-ac3, you only need to apply my 2.4.21-pre6 versions of 05-2.4.21-pre6-data-logging-36.diff.gz and 08-2.4.21-pre6-reiserfs-quota-26.diff.gz (but I have not tried this configuration yet). Enjoy. Bye, Oleg Hi Oleg, GRIN !!! I really would like to enjoy these, but you seem to be far away in future. Still no "official" patch seems to be out -- at least for me on here. (Yes, I'll wait and would not use bk.) Have your previously pending patches been included into 2.4.21-pre6 (they are: 02-trivial1.diff 03-more-mount-checks.diff 01-journal-overflow-fix.diff fromftp://ftp.namesys.com/pub/reiserfs-for-2.4/testing : iget5_locked_for_2.4.21-pre5-datalogging.diff.gz and posted to our ML @ "Wed, 12 Mar 2003 10:46:42 +0300" : direct-io-fix-II.diff ) ? My question only results from beeing unable to get them all applied to 2.4.21-pre5 with data-logging without rejects and me feeling unsafe to adjust them manually. Thanks, Manuel -- If we'll never find peace, freedom and democracy with our souls -- how can our world? We only need to begin. Yes, first step first, in peace...
Re: Hi
http://www.quickleadz.bz/mort/short/ Hi, I just got a 30 year fixed mortgage at 4.75%. I found this website where Lenders compete for your business. I thought you may want to look at it. http://www.quickleadz.bz/mort/short/ Thanks, William Burton Remove: http://www.quickleadz.bz/mort/rem/
Re: reiserfsck "block is in the tree already" error
On Fri, 2003-03-21 at 11:14, Vitaly Fertman wrote: > Hi, > > On Friday 21 March 2003 20:05, Alex Malinovich wrote: > > I've been trying to rebuild the tree on a reiserfs partition that seems > > to have gotten corrupted during a resize operation. Unfortunately, I've > > gone from having one or two directories not accessible to having the > > whole partition not accessible now. Everything seems to go ok until pass > > 2. At this point I start getting this error: > > > > "do_pass_2: The block (4901823) is in the tree already. Should not > > happen." > > It seems that reiserfsck was built on another computer, which has some > other libs version, not statically. Would you try to rebuild it and try > again. I just downloaded the source and built it and it worked! Thank you VERY much! -- Alex Malinovich Support Free Software, delete your Windows partition TODAY! Encrypted mail preferred. You can get my public key from any of the pgp.net keyservers. Key ID: A6D24837 signature.asc Description: This is a digitally signed message part
Re: datalogging and quota patches port to 2.4.21-pre6
Hello! On Sat, Mar 22, 2003 at 12:58:45AM +0100, Manuel Krause wrote: > GRIN !!! I really would like to enjoy these, but you seem to be far > away in future. Still no "official" patch seems to be out -- at least > for me on here. (Yes, I'll wait and would not use bk.) > Have your previously pending patches been included into 2.4.21-pre6 > (they are: 02-trivial1.diff >03-more-mount-checks.diff >01-journal-overflow-fix.diff > fromftp://ftp.namesys.com/pub/reiserfs-for-2.4/testing : > iget5_locked_for_2.4.21-pre5-datalogging.diff.gz > and posted to our ML @ "Wed, 12 Mar 2003 10:46:42 +0300" : > direct-io-fix-II.diff > ) ? Only patches that are visible at ftp://ftp.namesys.com/pub/reiserfs-for-2.4/2.4.20-pending were included into 2.4 tree. iget5_locked patch is in testing right now. direct-io-fix-II.diff have triggered some old long known minor metadata updating problems in case of unexpected crash and I am looking how to resolve that and trying various stuff. > My question only results from beeing unable to get them all applied to > 2.4.21-pre5 with data-logging without rejects and me feeling unsafe to > adjust them manually. Well, if you apply all of those patches from ftp://ftp.namesys.com/pub/reiserfs-for-2.4/2.4.20-pending on clean 2.4.20 (or whatever is needed for 2.4.21-pre5 only frpm ftp://ftp.namesys.com/pub/reiserfs-for-2.4/2.4.21-pre5.pending) and then apply data logging patches as if you have 2.4.21-pre6, and then iget5_locked stuff, it should work. Bye, Oleg
