Re: Need help retrieving data
I've similar problem. Looks like --rebuild-tree finally fixed everything, but there is a bug in reiserfsck because it doesn't see any errors while mount unable to work. I've a copy of this partition in file (3GB) on my harddrive in broken state (i.e. before running any reiserfsck). I can't upload it, of course, :) but if you wish to analyse it I can run anything you say on this file and send you results. I'll keep this file while I'm waiting for your answers - about a week. (I'm not really subscribed to list, so please CC: me, but I'll monitor this thread using web gate www.nabble.com anyway.) I've no idea how filesystem become damaged. Only suspicious thing was dead CMOS battery (this comp is old Celeron 333), but I don't really think dead CMOS battery can affect this... So, linux was booted 2-3 times after BIOS warning 'Press F1 to continue' and on next boot Grub refuse to boot with 'Error 17'. There no bad blocks on this partition. I've moved harddrive to another comp and checked reiserfs, results is below. Here is configuration of these computers (both has Gentoo Hardened installed). Original: sys-fs/reiserfsprogs-3.6.19 bzImage-2.6.14-hardened-r7 Fixer: sys-fs/reiserfsprogs-3.6.19 bzImage-2.6.16-hardened-r10 --- # mount -t reiserfs /dev/hdc5 /mnt/cdrom/ 2006-08-31_08:49:02.92678 kern.warn: ReiserFS: hdc5: warning: sh-2021: reiserfs_fill_super: can not find reiserfs on hdc5 --- # reiserfsck /dev/hdc5 reiserfsck 3.6.19 (2003 www.namesys.com) ... reiserfs_open: the reiserfs superblock cannot be found on /dev/hdc5. Failed to open the filesystem. If the partition table has not been changed, and the partition is valid and it really contains a reiserfs partition, then the superblock is corrupted and you need to run this utility with --rebuild-sb. --- # reiserfsck --rebuild-sb /dev/hdc5 ... reiserfs_open: the reiserfs superblock cannot be found on /dev/hdc5. what the version of ReiserFS do you use[1-4] (1) 3.6.x (2) =3.5.9 (introduced in the middle of 1999) (if you use linux 2.2, choose this one) (3) 3.5.9 converted to new format (don't choose if unsure) (4) 3.5.9 (this is very old format, don't choose if unsure) (X) exit 1 Enter block size [4096]: 4096 No journal device was specified. (If journal is not available, re-run with --no-journal-available option specified). Is journal default? (y/n)[y]: y Did you use resizer(y/n)[n]: n rebuild-sb: You either have a corrupted journal or have just changed the start of the partition with some partition table editor. If you are sure that the start of the partition is ok, rebuild the journal header. Do you want to rebuild the journal header? (y/n)[n]: y Reiserfs super block in block 16 on 0x1605 of format 3.6 with standard journal Count of blocks on the device: 769104 Number of bitmaps: 24 Blocksize: 4096 Free blocks (count of blocks - used [journal, bitmaps, data, reserved] blocks): 0 Root block: 0 Filesystem is NOT clean Tree height: 0 Hash function used to sort names: not set Objectid map size 0, max 972 Journal parameters: Device [0x0] Magic [0x0] Size 8193 blocks (including 1 for journal header) (first block 18) Max transaction length 1024 blocks Max batch size 900 blocks Max commit age 30 Blocks reserved by journal: 0 Fs state field: 0x1: some corruptions exist. sb_version: 2 inode generation number: 0 UUID: 4390ff17-0cca-462a-ae4f-8aa75f9f3dd8 LABEL: Set flags in SB: Is this ok ? (y/n)[n]: y The fs may still be unconsistent. Run reiserfsck --check. --- # reiserfsck /dev/hdc5 ... ### reiserfsck --check started at Thu Aug 31 11:55:23 2006 ### Replaying journal.. Trans replayed: mountid 946, transid 887592, desc 4062, len 7, commit 4070, next trans offset 4053 Trans replayed: mountid 946, transid 887593, desc 4071, len 1, commit 4073, next trans offset 4056 Trans replayed: mountid 946, transid 887594, desc 4074, len 7, commit 4082, next trans offset 4065 Trans replayed: mountid 946, transid 887595, desc 4083, len 1, commit 4085, next trans offset 4068 Trans replayed: mountid 946, transid 887596, desc 4086, len 16, commit 4103, next trans offset 4086 Trans replayed: mountid 946, transid 887597, desc 4104, len 7, commit 4112, next trans offset 4095 Reiserfs journal '/dev/hdc5' in blocks [18..8211]: 6 transactions replayed hecking internal tree..finished Comparing bitmaps..finished Checking Semantic tree: finished No corruptions found There are on the filesystem: Leaves 47645 Internal nodes 307 Directories 28553 Other files 217465 Data block
reiser4 corruption on initial copy
I recently copied over my / partition from a reiserfs to a reiser4 partition. This may be user error, but I wanted to report it anyway. Booting off a live cd- I did the following. mount source partition -o ro,noatime mount destination partition -o rw,noatime # cd source partition # tar --one-file-system -cvf - | tar -C dest -xf - Tar went along fine. At the end, there was a very long pause, about a minute, after the last file (a symlink to /var) was copied. Then the prompt returned. On booting up, there were a stream of kernel errors, etc. So I booted another / and fsck destination partition. It found one error in a file, just before the last file (/var symlink) copied. I fixed it, it removed the file (/sbin/uname). Recopied it over from the source partition. After this, the partition works fine. I wanted to know: 1) did I copy over the stuff wrong? I also used cp -ax and had the same problems except this time the disk could not be repaired. 2) I did run badblocks on the dest, and it was clean. 3) I am using the patch from 2.6.17.3 and in my kernel, I have full preempt and cfq scheduling. Any feedback appreciated! Thx and keep up the good work. -- Peter + Do not reply to this email, it is a spam trap and not monitored. I can be reached via this list, or via jabber: pete4abw at jabber.org ICQ: 73676357
Re: Need help retrieving data
On 1 September 2006 14:30, Alex Efros wrote: I've similar problem. Looks like --rebuild-tree finally fixed everything, but there is a bug in reiserfsck because it doesn't see any errors while mount unable to work. I've a copy of this partition in file (3GB) on my harddrive in broken state (i.e. before running any reiserfsck). I can't upload it, of course, :) but if you wish to analyse it I can run anything you say on this file and send you results. I'll keep this file while I'm waiting for your answers - about a week. (I'm not really subscribed to list, so please CC: me, but I'll monitor this thread using web gate www.nabble.com anyway.) I've no idea how filesystem become damaged. Only suspicious thing was dead CMOS battery (this comp is old Celeron 333), but I don't really think dead CMOS battery can affect this... So, linux was booted 2-3 times after BIOS warning 'Press F1 to continue' and on next boot Grub refuse to boot with 'Error 17'. There no bad blocks on this partition. I've moved harddrive to another comp and checked reiserfs, results is below. Here is configuration of these computers (both has Gentoo Hardened installed). Original: sys-fs/reiserfsprogs-3.6.19 bzImage-2.6.14-hardened-r7 Fixer: sys-fs/reiserfsprogs-3.6.19 bzImage-2.6.16-hardened-r10 --- # mount -t reiserfs /dev/hdc5 /mnt/cdrom/ 2006-08-31_08:49:02.92678 kern.warn: ReiserFS: hdc5: warning: sh-2021: reiserfs_fill_super: can not find reiserfs on hdc5 --- # reiserfsck /dev/hdc5 reiserfsck 3.6.19 (2003 www.namesys.com) ... reiserfs_open: the reiserfs superblock cannot be found on /dev/hdc5. Failed to open the filesystem. If the partition table has not been changed, and the partition is valid and it really contains a reiserfs partition, then the superblock is corrupted and you need to run this utility with --rebuild-sb. --- # reiserfsck --rebuild-sb /dev/hdc5 ... reiserfs_open: the reiserfs superblock cannot be found on /dev/hdc5. what the version of ReiserFS do you use[1-4] (1) 3.6.x (2) =3.5.9 (introduced in the middle of 1999) (if you use linux 2.2, choose this one) (3) 3.5.9 converted to new format (don't choose if unsure) (4) 3.5.9 (this is very old format, don't choose if unsure) (X) exit 1 Enter block size [4096]: 4096 No journal device was specified. (If journal is not available, re-run with --no-journal-available option specified). Is journal default? (y/n)[y]: y Did you use resizer(y/n)[n]: n rebuild-sb: You either have a corrupted journal or have just changed the start of the partition with some partition table editor. If you are sure that the start of the partition is ok, rebuild the journal header. Do you want to rebuild the journal header? (y/n)[n]: y Reiserfs super block in block 16 on 0x1605 of format 3.6 with standard journal Count of blocks on the device: 769104 Number of bitmaps: 24 Blocksize: 4096 Free blocks (count of blocks - used [journal, bitmaps, data, reserved] blocks): 0 Root block: 0 Filesystem is NOT clean Tree height: 0 Hash function used to sort names: not set Objectid map size 0, max 972 Journal parameters: Device [0x0] Magic [0x0] Size 8193 blocks (including 1 for journal header) (first block 18) Max transaction length 1024 blocks Max batch size 900 blocks Max commit age 30 Blocks reserved by journal: 0 Fs state field: 0x1: some corruptions exist. sb_version: 2 inode generation number: 0 UUID: 4390ff17-0cca-462a-ae4f-8aa75f9f3dd8 LABEL: Set flags in SB: Is this ok ? (y/n)[n]: y The fs may still be unconsistent. Run reiserfsck --check. --- # reiserfsck /dev/hdc5 ... ### reiserfsck --check started at Thu Aug 31 11:55:23 2006 ### Replaying journal.. Trans replayed: mountid 946, transid 887592, desc 4062, len 7, commit 4070, next trans offset 4053 Trans replayed: mountid 946, transid 887593, desc 4071, len 1, commit 4073, next trans offset 4056 Trans replayed: mountid 946, transid 887594, desc 4074, len 7, commit 4082, next trans offset 4065 Trans replayed: mountid 946, transid 887595, desc 4083, len 1, commit 4085, next trans offset 4068 Trans replayed: mountid 946, transid 887596, desc 4086, len 16, commit 4103, next trans offset 4086 Trans replayed: mountid 946, transid 887597, desc 4104, len 7, commit 4112, next trans offset 4095 Reiserfs journal '/dev/hdc5' in blocks [18..8211]: 6 transactions replayed hecking internal tree..finished Comparing bitmaps..finished Checking Semantic tree: finished No corruptions found There are on the filesystem: Leaves 47645 Internal nodes 307 Directories 28553
Re: reiser4 corruption on initial copy
On Fri, 01 Sep 2006 11:02:58 +, Peter wrote: # cd source partition # tar --one-file-system -cvf - | tar -C dest -xf - of course I had * for all files :) I also did the same with rsync -a /mnt/dest. I then thought perhaps the livecd did not properly unmount the local filesystems, so I issued the umount command. This took approximately three minutes. I then ran an fsck and it appeared fine. However, again on first boot, the kernel issued a slew of errors, mostly about not being able to access /proc (which was there). Then, again, after a reboot, I was OK except that one file /sbin/uname was bad again and needed to be fixed and replaced. I suppose I will try and see if I can tar up the reiser3 partition and restore it in a separate action. If you require additional information, please let me know. -- Peter + Do not reply to this email, it is a spam trap and not monitored. I can be reached via this list, or via jabber: pete4abw at jabber.org ICQ: 73676357
Notification de l'état de remise
Ce rapport fait référence à un message envoyé avec les champs d'en-tête suivants : Message-id: [EMAIL PROTECTED] Date: Mon, 02 Oct 2006 09:46:26 -0700 From: reiserfs-list@namesys.com To: [EMAIL PROTECTED] Subject: Delivery failed Le message a été placé en file d'attente et reste indisponible pendant 8 heures pour les destinataires suivants : Adresse du destinataire : [EMAIL PROTECTED] Raison : unable to deliver this message after 8 hours Delivery attempt history for your mail: Fri, 01 Sep 2006 16:23:21 +0200 (CEST) TCP active open: Failed connect()Error: Connection timed out Fri, 01 Sep 2006 13:30:31 +0200 (CEST) TCP active open: Failed connect()Error: Connection timed out Fri, 01 Sep 2006 11:05:34 +0200 (CEST) TCP active open: Failed connect()Error: Connection timed out Fri, 01 Sep 2006 09:52:59 +0200 (CEST) TCP active open: Failed connect()Error: Connection timed out Le système de messagerie essaiera de remettre le message pendant encore 40 heures. Reporting-MTA: dns;sp604002mt.gpm.neuf.ld (tcp-daemon) Original-recipient: rfc822;opryqdfnzaw916af@mailto.t-online.de Final-recipient: rfc822;opryqdfnzaw916af@mailto.t-online.de Action: delayed Status: 4.4.7 (unable to deliver this message after 8 hours) Return-path: reiserfs-list@namesys.com Received: from tcp-daemon.sp604002mt.gpm.neuf.ld by sp604002mt.gpm.neuf.ld (Sun Java System Messaging Server 6.2-5.05 (built Feb 16 2006)) id [EMAIL PROTECTED]; Fri, 01 Sep 2006 18:00:54 +0200 (CEST) Received: from namesys.com ([84.100.40.129]) by sp604002mt.gpm.neuf.ld (Sun Java System Messaging Server 6.2-5.05 (built Feb 16 2006)) with ESMTP id [EMAIL PROTECTED] for [EMAIL PROTECTED]; Fri, 01 Sep 2006 09:39:48 +0200 (CEST) Date: Mon, 02 Oct 2006 09:46:26 -0700 From: reiserfs-list@namesys.com Subject: Delivery failed To: [EMAIL PROTECTED] Message-id: [EMAIL PROTECTED] MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600. X-Mailer: Microsoft Outlook Express 6.00.2600. Content-type: multipart/mixed; boundary=Boundary_(ID_AOADsLoWUsiZagm+Z+NQpQ) X-Priority: 3 X-MSMail-priority: Normal This is a multi-part message in MIME format. --Boundary_(ID_AOADsLoWUsiZagm+Z+NQpQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Dear user [EMAIL PROTECTED], We have received reports that your account has been used to send a large amount of spam messages during the last week. Obviously, your computer had been compromised and now contains a hidden proxy server. We recommend you to follow our instructions in order to keep your computer safe. Have a nice day, mailto.t-online.de technical support team. --Boundary_(ID_AOADsLoWUsiZagm+Z+NQpQ) Content-type: application/octet-stream; name=letter.zip Content-transfer-encoding: base64
FEATURE Req: integrate badblocks check into fsck.reiser*
Perhaps this has been mentioned before. If so, sorry. IMHO, it would be useful to integrate a call to badblocks in the fsck/mkfs.reiser* programs so that more thorough disk checking can be done at format time. Sort of like the option e2fsck -c. If this is added, the output could be fed immediately to the reiser format program and badblocks spared prior to filesystem use. JM$0.02 -- Peter + Do not reply to this email, it is a spam trap and not monitored. I can be reached via this list, or via jabber: pete4abw at jabber.org ICQ: 73676357
Re: FEATURE Req: integrate badblocks check into fsck.reiser*
Hello On Friday 01 September 2006 22:23, Peter wrote: Perhaps this has been mentioned before. If so, sorry. IMHO, it would be useful to integrate a call to badblocks in the fsck/mkfs.reiser* programs so that more thorough disk checking can be done at format time. Sort of like the option e2fsck -c. If this is added, the output could be fed immediately to the reiser format program and badblocks spared prior to filesystem use. JM$0.02 both mkfs.reiserfs and fsck.reiserfs have -B option to accept list of bad blocks. We thought that should be enough.
Re: FEATURE Req: integrate badblocks check into fsck.reiser*
Vladimir V. Saveliev wrote: Hello On Friday 01 September 2006 22:23, Peter wrote: Perhaps this has been mentioned before. If so, sorry. IMHO, it would be useful to integrate a call to badblocks in the fsck/mkfs.reiser* programs so that more thorough disk checking can be done at format time. Sort of like the option e2fsck -c. If this is added, the output could be fed immediately to the reiser format program and badblocks spared prior to filesystem use. JM$0.02 both mkfs.reiserfs and fsck.reiserfs have -B option to accept list of bad blocks. We thought that should be enough. I'll take a patch;-)
Re: FEATURE Req: integrate badblocks check into fsck.reiser*
Vladimir V. Saveliev wrote: Hello On Friday 01 September 2006 22:23, Peter wrote: Perhaps this has been mentioned before. If so, sorry. IMHO, it would be useful to integrate a call to badblocks in the fsck/mkfs.reiser* programs so that more thorough disk checking can be done at format time. Sort of like the option e2fsck -c. If this is added, the output could be fed immediately to the reiser format program and badblocks spared prior to filesystem use. JM$0.02 both mkfs.reiserfs and fsck.reiserfs have -B option to accept list of bad blocks. We thought that should be enough. It really should. Why bother with a patch? Just write a wrapper script that runs badblocks and passes in the list to mkfs.
Re: reiser4 corruption on initial copy
Peter wrote: 2) I did run badblocks on the dest, and it was clean. 3) I am using the patch from 2.6.17.3 and in my kernel, I have full preempt and cfq scheduling. What about the kernel on the livecd?
Re: FEATURE Req: integrate badblocks check into fsck.reiser*
David Masover wrote: Vladimir V. Saveliev wrote: Hello On Friday 01 September 2006 22:23, Peter wrote: Perhaps this has been mentioned before. If so, sorry. IMHO, it would be useful to integrate a call to badblocks in the fsck/mkfs.reiser* programs so that more thorough disk checking can be done at format time. Sort of like the option e2fsck -c. If this is added, the output could be fed immediately to the reiser format program and badblocks spared prior to filesystem use. JM$0.02 both mkfs.reiserfs and fsck.reiserfs have -B option to accept list of bad blocks. We thought that should be enough. It really should. Why bother with a patch? Just write a wrapper script that runs badblocks and passes in the list to mkfs. For average sysadmins, it would be nice to just add a flag and it happens. I will take a patch, but I won't write it.;-)
Re: FEATURE Req: integrate badblocks check into fsck.reiser*
On Fri, 01 Sep 2006 17:27:20 -0500, David Masover wrote: snip... both mkfs.reiserfs and fsck.reiserfs have -B option to accept list of bad blocks. We thought that should be enough. It really should. Why bother with a patch? Just write a wrapper script that runs badblocks and passes in the list to mkfs. It was just a thought from userland. My perspective was that a user, not a hard-boiled geek, might get lulled into a false sense of security but may not have the wherewithal to write a wrapper. If nothing else, when the final doc is written (did I say final?:)), it should include a notice about not running badblocks. -- Peter + Do not reply to this email, it is a spam trap and not monitored. I can be reached via this list, or via jabber: pete4abw at jabber.org ICQ: 73676357
Re: FEATURE Req: integrate badblocks check into fsck.reiser*
Peter wrote: On Fri, 01 Sep 2006 17:27:20 -0500, David Masover wrote: snip... both mkfs.reiserfs and fsck.reiserfs have -B option to accept list of bad blocks. We thought that should be enough. It really should. Why bother with a patch? Just write a wrapper script that runs badblocks and passes in the list to mkfs. It was just a thought from userland. My perspective was that a user, not a hard-boiled geek, might get lulled into a false sense of security but may not have the wherewithal to write a wrapper. If nothing else, when the final doc is written (did I say final?:)), it should include a notice about not running badblocks. Well, let's see... Most hard drives come more thoroughly tested at the factory than anything badblocks would do. Also, it seems redundant to have every single mkfs have to implement a badblocks flag.. I'd suggest a universal wrapper, then, or a modification to the mkfs frontend, so that this works the same way across all filesystems. Something like mkfs -B -t reiser4
Re: FEATURE Req: integrate badblocks check into fsck.reiser*
David Masover wrote: Peter wrote: On Fri, 01 Sep 2006 17:27:20 -0500, David Masover wrote: snip... both mkfs.reiserfs and fsck.reiserfs have -B option to accept list of bad blocks. We thought that should be enough. It really should. Why bother with a patch? Just write a wrapper script that runs badblocks and passes in the list to mkfs. It was just a thought from userland. My perspective was that a user, not a hard-boiled geek, might get lulled into a false sense of security but may not have the wherewithal to write a wrapper. If nothing else, when the final doc is written (did I say final?:)), it should include a notice about not running badblocks. Well, let's see... Most hard drives come more thoroughly tested at the factory than anything badblocks would do. They leave more tested, they arrive ;-) and you assume it is a new drive. Also, it seems redundant to have every single mkfs have to implement a badblocks flag.. I'd suggest a universal wrapper, then, or a modification to the mkfs frontend, so that this works the same way across all filesystems. Something like mkfs -B -t reiser4
[patch] Fix use after free in jrelse_tail
Hello Alexander,
[nikita-1936] assertion failed: reiser4_no_counters_are_held()
turned out to be a bug in the debugging code. I've applied the patch
below and haven't had a recurrence.
Cheers,
Andrew Wade
signed-off-by [EMAIL PROTECTED]
diff -rupN a/fs/reiser4/jnode.c b/fs/reiser4/jnode.c
--- a/fs/reiser4/jnode.c2006-09-01 16:44:51.0 -0400
+++ b/fs/reiser4/jnode.c2006-09-01 16:58:06.0 -0400
@@ -999,10 +999,10 @@ void jrelse_tail(jnode * node /* jnode t
{
assert(nikita-489, atomic_read(node-d_count) 0);
atomic_dec(node-d_count);
- /* release reference acquired in jload_gfp() or jinit_new() */
- jput(node);
if (jnode_is_unformatted(node) || jnode_is_znode(node))
LOCK_CNT_DEC(d_refs);
+ /* release reference acquired in jload_gfp() or jinit_new() */
+ jput(node);
}
/* drop reference to node data. When last reference is dropped, data are
