Re: Need help retrieving data
Hello
On Saturday 02 September 2006 15:26, Alexander Zarochentsev wrote:
On 2 September 2006 13:32, Alex Efros wrote:
Hi!
So, I did everything correctly to fix it? --rebuild-tree doesn't
broke anything?
usually not.
but reiserfsck --rebuild-tree is a complex operation. It has a possibility
to insert wrong blocks into the tree if your fs was used to store another
reiserfs image. and you have a chance to hit new reiserfsck bug.
unfortunately no fix for fsck is available yet.
I think it is not fsck bug. When hash code is unknown - it can be defined on
mount. The attached patch is supposed to fix broken hash detection.
If you provide fixed reiserfsck version, I can run it on my image to
test it and confirm image become mountabe after --rebuild-sb. But I
can't leave this 3GB image on my drive for months, so if you wish
to make the partition mountable again it is enough to change
one byte in the super block from 0 (hash is not set) to 3 (r5 hash).
It can be done by a hex editor.
hexdump -C of block #16 (reiserfs uses 4k-size blocks, numbers start with
0):
...
0030 06 00 01 00 52 65 49 73 45 72 32 46 73 00 00 00
|ReIsEr2Fs...| 0040 03 00 00 00 05 00 c6 04 02 00 00 00 89 28 00
00 |..ф.┴(..| ^^
this byte.
...
according with:
struct reiserfs_super_block_v1 {
...
char s_magic[10]; /* reiserfs magic string indicates that
* file system is reiserfs:
* ReIsErFs or ReIsEr2Fs or ReIsEr3Fs
*/ __le16 s_fs_state; /* it is set to used by fsck to mark which *
phase of rebuilding is done */
__le32 s_hash_function_code;/* indicate, what hash function is
being use ...
this testing from me - please provide fixed version in about 7-10
days or at least notify me when it will be ready - if your need more
time I probably move it to DVD-RW.
I already have a broken fs to experiment with.
diff -puN fs/reiserfs/super.c~reiserfs-fix-fill_super fs/reiserfs/super.c
--- linux-2.6.18-rc4-mm1/fs/reiserfs/super.c~reiserfs-fix-fill_super 2006-09-01 21:13:02.0 +0400
+++ linux-2.6.18-rc4-mm1-vs/fs/reiserfs/super.c 2006-09-03 11:33:12.0 +0400
@@ -1384,7 +1384,7 @@ static __u32 find_hash_out(struct super_
do { // Some serious goto-hater was there ;)
u32 teahash, r5hash, yurahash;
- make_cpu_key(key, inode, ~0, TYPE_DIRENTRY, 3);
+ make_cpu_key(key, inode, LLONG_MAX, TYPE_DIRENTRY, 3);
retval = search_by_entry_key(s, key, path, de);
if (retval == IO_ERROR) {
pathrelse(path);
@@ -1549,7 +1549,7 @@ static int reiserfs_fill_super(struct su
struct reiserfs_super_block *rs;
char *jdev_name;
struct reiserfs_sb_info *sbi;
- int errval = -EINVAL;
+ int errval;
sbi = kmalloc(sizeof(struct reiserfs_sb_info), GFP_KERNEL);
if (!sbi) {
@@ -1576,12 +1576,14 @@ static int reiserfs_fill_super(struct su
if (reiserfs_parse_options
(s, (char *)data, (sbi-s_mount_opt), blocks, jdev_name,
commit_max_age) == 0) {
+ errval = -EINVAL;
goto error;
}
if (blocks) {
SWARN(silent, s, jmacd-7: reiserfs_fill_super: resize option
for remount only);
+ errval = -EINVAL;
goto error;
}
@@ -1593,6 +1595,7 @@ static int reiserfs_fill_super(struct su
SWARN(silent, s,
sh-2021: reiserfs_fill_super: can not find reiserfs on %s,
reiserfs_bdevname(s));
+ errval = -EINVAL;
goto error;
}
@@ -1610,6 +1613,7 @@ static int reiserfs_fill_super(struct su
You may need to run fsck or increase size of your LVM partition);
SWARN(silent, s,
Or may be you forgot to reboot after fdisk when it told you to);
+ errval = -EINVAL;
goto error;
}
@@ -1649,6 +1653,7 @@ static int reiserfs_fill_super(struct su
if (journal_init(s, jdev_name, old_format, commit_max_age)) {
SWARN(silent, s,
sh-2022: reiserfs_fill_super: unable to initialize journal space);
+ errval = -ENODEV;
goto error;
} else {
jinit_done = 1; /* once this is set, journal_release must be called
@@ -1658,11 +1663,14 @@ static int reiserfs_fill_super(struct su
if (reread_meta_blocks(s)) {
SWARN(silent, s,
jmacd-9: reiserfs_fill_super: unable to reread meta blocks after journal init);
+ errval = -ENODEV;
goto error;
}
- if (replay_only(s))
+ if (replay_only(s)) {
+ errval = -EINVAL;
goto error;
+ }
if (bdev_read_only(s-s_bdev) !(s-s_flags MS_RDONLY)) {
SWARN(silent, s,
@@ -1677,6 +1685,7 @@ static int reiserfs_fill_super(struct su
if (!root_inode) {
SWARN(silent, s,
jmacd-10: reiserfs_fill_super: get root inode failed);
+ errval = -ENODEV;
goto error;
}
@@ -1688,6 +1697,7 @@ static int reiserfs_fill_super(struct su
s-s_root = d_alloc_root(root_inode);
if (!s-s_root) {
iput(root_inode);
+ errval = -ENOMEM;
goto error;
}
// define and initialize hash function
@@ -1695,6 +1705,7 @@ static int
Re: reiser4 corruption on initial copy
On Fri, 01 Sep 2006 11:02:58 +, Peter wrote: 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. snip... I was able to duplicate the problem. Apparently, the Sabayon live cd does not unmount locally mounted partitions. Thus, the reiser4 partitions are unclean. When I boot up to the newly created and copied partition, I get the errors I referred to earlier. By manually umounting the partitions I create or copy from -- including /tmp partitions or /var partitions. I do not get the boot time errors. HTH -- 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
Reiser FS will not boot after crash
Hi, I am observing the following Reiser failure: I am trying to use camorama with a Creative WebCam Live spca5xx driver (recently downloaded and compiled) . Camorama does not start and computer freezes (no response to mouse, or keyboard. Can't change to terminal window. Reset or pull plug leaves Knoppix 5.0.1-DVD unbootable: The actual message from GRUB is inconsistent filesystem?! From a boot loader? The 'fix' is even stranger. I execute fsck.reiserfs from another OS partition on the Knoppix 5.0.1-DVD partition (takes forever). Somehow 'reading' the Knoppix filesystem 'fixes' whatever was preventing Knoppix 5.0.1-DVD from booting. I am curious what your comments and/or suggestions might be? regards to all Linuxers, john
Re: Reiser FS will not boot after crash
Hello On Monday 04 September 2006 23:26, [EMAIL PROTECTED] wrote: Hi, I am observing the following Reiser failure: I am trying to use camorama with a Creative WebCam Live spca5xx driver (recently downloaded and compiled) . Camorama does not start and computer freezes (no response to mouse, or keyboard. Can't change to terminal window. Reset or pull plug leaves Knoppix 5.0.1-DVD unbootable: The actual message from GRUB is inconsistent filesystem?! From a boot loader? after unclean shutdown journal reply is necessary to return reiserfs to consistent state. Maybe GRUB did not do that? The 'fix' is even stranger. I execute fsck.reiserfs from another OS partition on the Knoppix 5.0.1-DVD partition (takes forever). Did fsck complete? What did it report? Somehow 'reading' the Knoppix filesystem 'fixes' whatever was preventing Knoppix 5.0.1-DVD from booting. fsck replayed the journal. Does camorama work now? If it still causes computer freeze - can you please install serial or network console and try to catch what does kernel output when it freezes. I am curious what your comments and/or suggestions might be? regards to all Linuxers, john
Re: Reiser FS will not boot after crash
On Mon, 04 Sep 2006 23:33:27 +0400, Vladimir V. Saveliev said: after unclean shutdown journal reply is necessary to return reiserfs to consistent state. Maybe GRUB did not do that? A case can be made that GRUB should be keeping its grubby little paws off the filesystem journal. It's a *bootloader*. It's only purpose in life is to load other code that can make intelligent decisions about things like how (or even whether) to replay a filesystem journal. pgpPJnsG2OrrF.pgp Description: PGP signature
Re: Reiser FS will not boot after crash
Hello On Tuesday 05 September 2006 00:30, [EMAIL PROTECTED] wrote: On Mon, 04 Sep 2006 23:33:27 +0400, Vladimir V. Saveliev said: after unclean shutdown journal reply is necessary to return reiserfs to consistent state. Maybe GRUB did not do that? A case can be made that GRUB should be keeping its grubby little paws off the filesystem journal. It's a *bootloader*. It's only purpose in life is to load other code that can make intelligent decisions about things like how (or even whether) to replay a filesystem journal. Yes, I did not say that grub has to replay a journal, I just tried to guess why grub failed to boot and why things went ok after fsck.
Re: Reiser FS will not boot after crash
Hi, You make some good points. I wonder what the right fix is? I certainly think the user should not be stopped from booting and then get the inconsistent filesystem message over and over again as I do. Perhaps GRUB should offer to 'replay' the filesystem after discovering that the filesystem is inconsistent. I am not sure what other choices there are since the kernel and the initial boot filesystem are presumably not loadable? john On Tue, 5 Sep 2006, Vladimir V. Saveliev wrote: Hello On Tuesday 05 September 2006 00:30, [EMAIL PROTECTED] wrote: On Mon, 04 Sep 2006 23:33:27 +0400, Vladimir V. Saveliev said: after unclean shutdown journal reply is necessary to return reiserfs to consistent state. Maybe GRUB did not do that? A case can be made that GRUB should be keeping its grubby little paws off the filesystem journal. It's a *bootloader*. It's only purpose in life is to load other code that can make intelligent decisions about things like how (or even whether) to replay a filesystem journal. Yes, I did not say that grub has to replay a journal, I just tried to guess why grub failed to boot and why things went ok after fsck.
Re: Reiser FS will not boot after crash
Hi - Thanks for your reply. Further comments below: On Mon, 4 Sep 2006, Vladimir V. Saveliev wrote: Hello On Monday 04 September 2006 23:26, [EMAIL PROTECTED] wrote: Hi, I am observing the following Reiser failure: I am trying to use camorama with a Creative WebCam Live spca5xx driver (recently downloaded and compiled) . Camorama does not start and computer freezes (no response to mouse, or keyboard. Can't change to terminal window. Reset or pull plug leaves Knoppix 5.0.1-DVD unbootable: The actual message from GRUB is inconsistent filesystem?! From a boot loader? after unclean shutdown journal reply is necessary to return reiserfs to consistent state. Maybe GRUB did not do that? You are probably correct. I don't know how to tell if GRUB did or did not do this. The 'fix' is even stranger. I execute fsck.reiserfs from another OS partition on the Knoppix 5.0.1-DVD partition (takes forever). Did fsck complete? What did it report? Yes, fsck did complete with no problems found? This is what confuses me. I had assumed it would NOT modify the filesystem unless you gave it permission. From what I can see it must have rewritten at least some part of the filesystem. Somehow 'reading' the Knoppix filesystem 'fixes' whatever was preventing Knoppix 5.0.1-DVD from booting. fsck replayed the journal. Sounds like it to me. Does camorama work now? No, camorama (loaded by apt-get install camorama) crashes Knoppix 5.0.1 every time. That said all the programs supplied spca5xx driver and friends work OK. Curiously, gnetmeeting, or whatever it's called, cannot connect to the video webcam? Maybe the next version of the driver or gnetmeeting will fix this? If it still causes computer freeze - can you please install serial or network console and try to catch what does kernel output when it freezes. I will try to do that. I assume you mean do a tail -f /var/log/messages from a remote console? Any other files of interest? I am curious what your comments and/or suggestions might be? regards to all Linuxers, john
Re: Reiser FS will not boot after crash
[EMAIL PROTECTED] wrote: On Mon, 04 Sep 2006 23:33:27 +0400, Vladimir V. Saveliev said: after unclean shutdown journal reply is necessary to return reiserfs to consistent state. Maybe GRUB did not do that? A case can be made that GRUB should be keeping its grubby little paws off the filesystem journal. It's a *bootloader*. It's only purpose in life is to load other code that can make intelligent decisions about things like how (or even whether) to replay a filesystem journal. But, unlike Lilo, Grub usually has to load that other code from a filesystem, which means it's already doing more than what bootloaders traditionally do. If it was up to me, we'd all be using LinuxBIOS and kexec, and it wouldn't be an issue.
