journal size==0 [reiserfs 3.6, reiserutils 3.x.1b]

journal size==0 [reiserfs 3.6, reiserutils 3.x.1b]

[Thomas Wiedemann]

hi reiserfs-developers,

i cannot mount my reiserfs partition any more, because of that:

super-459: read_super_block: super found at block 16 is within its own log. It must not be of this format type.


so, here's the story how i "created" this error and some details:

due a hardware failure (the harddisk?), i got some weird error messages:

Apr 13 17:32:13 hq kernel: hdb: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Apr 13 17:32:13 hq kernel: hdb: dma_intr: error=0x84 { DriveStatusError BadCRC }
(...)

followed by some filesystem errors:

Apr 13 17:33:46 hq kernel: is_tree_node: node level 432 does not match to the expected one 1
Apr 13 17:33:46 hq kernel: vs-5150: search_by_key: invalid format found in block 19232. Fsck?
Apr 13 17:33:46 hq kernel: vs-13070: reiserfs_read_inode2: i/o failure occurred trying to find stat data of [1584 1590 0x0
 SD]
...and so on....

i had to reboot my pc, the disk was ok, but the partition was dead.
so i downloaded the newest reiserfs-utils (3.x.1b) and tried to repair it.
the superblock seemed to be screwed up, so...

# reiserfsck /dev/hdb1 --rebuild-sb --no-journal-available
# reiserfsck --rebuild-tree

...did some work on the filesystem, but i'm still not able to mount it, because while rebuilding the superblock, fsck did not make a journal on the device:

# debugreiserfs /dev/hdb1

<-------------debugreiserfs, 2002------------->
reiserfsprogs 3.x.1b


Filesystem state: consistent

Reiserfs super block in block 16 on 0x341 of format 3.6 with standard journal
Count of blocks on the device: 11273605
Number of bitmaps: 345
Blocksize: 4096
Free blocks (count of blocks - used [journal, bitmaps, data, reserved] blocks): 1611835
Root block: 431
Filesystem is cleanly umounted
Tree height: 5
Hash function used to sort names: "r5"
Objectid map size 972, max 972
Journal parameters:
        Device [0x0]
        Magic [0x0]
        Size 1 blocks (including 1 for journal header) (first block 0)
        Max transaction length 0 blocks
        Max batch size 0 blocks
        Max commit age 0
Blocks reserved by journal: 0
Fs state field: 0x0
sb_version: 2
inode generation number: 0
UUID: c0ce572a-1ed0-4827-b72a-8aef5cdb2015
LABEL: 
Set flags in SB:


now, that the journal's size is only one block, mount fails, while fsck claims everything to be alright (mount -o nolog also fails).
i don't know if this is a bug in reiserfsck....and maybe there is a way to insert a journal into between the rootblock and the superblock (where the journal was before the crash...)?

thanks, thomas.

Re: journal size==0 [reiserfs 3.6, reiserutils 3.x.1b]

[Hans Reiser]

Thomas Wiedemann wrote:

>hi reiserfs-developers,
>
>i cannot mount my reiserfs partition any more, because of that:
>
>super-459: read_super_block: super found at block 16 is within its own log. It must not be of this format type.
>
>
>so, here's the story how i "created" this error and some details:
>
>due a hardware failure (the harddisk?), i got some weird error messages:
>
>Apr 13 17:32:13 hq kernel: hdb: dma_intr: status=0x51 { DriveReady SeekComplete Error }
>Apr 13 17:32:13 hq kernel: hdb: dma_intr: error=0x84 { DriveStatusError BadCRC }
>(...)
>
>followed by some filesystem errors:
>
>Apr 13 17:33:46 hq kernel: is_tree_node: node level 432 does not match to the expected one 1
>Apr 13 17:33:46 hq kernel: vs-5150: search_by_key: invalid format found in block 19232. Fsck?
>Apr 13 17:33:46 hq kernel: vs-13070: reiserfs_read_inode2: i/o failure occurred trying to find stat data of [1584 1590 0x0
> SD]
>...and so on....
>
>i had to reboot my pc, the disk was ok, but the partition was dead.
>so i downloaded the newest reiserfs-utils (3.x.1b) and tried to repair it.
>the superblock seemed to be screwed up, so...
>
># reiserfsck /dev/hdb1 --rebuild-sb --no-journal-available
># reiserfsck --rebuild-tree
>
>...did some work on the filesystem, but i'm still not able to mount it, because while rebuilding the superblock, fsck did not make a journal on the device:
>
># debugreiserfs /dev/hdb1
>
><-------------debugreiserfs, 2002------------->
>reiserfsprogs 3.x.1b
>
>
>Filesystem state: consistent
>
>Reiserfs super block in block 16 on 0x341 of format 3.6 with standard journal
>Count of blocks on the device: 11273605
>Number of bitmaps: 345
>Blocksize: 4096
>Free blocks (count of blocks - used [journal, bitmaps, data, reserved] blocks): 1611835
>Root block: 431
>Filesystem is cleanly umounted
>Tree height: 5
>Hash function used to sort names: "r5"
>Objectid map size 972, max 972
>Journal parameters:
>        Device [0x0]
>        Magic [0x0]
>        Size 1 blocks (including 1 for journal header) (first block 0)
>        Max transaction length 0 blocks
>        Max batch size 0 blocks
>        Max commit age 0
>Blocks reserved by journal: 0
>Fs state field: 0x0
>sb_version: 2
>inode generation number: 0
>UUID: c0ce572a-1ed0-4827-b72a-8aef5cdb2015
>LABEL: 
>Set flags in SB:
>
>
>now, that the journal's size is only one block, mount fails, while fsck claims everything to be alright (mount -o nolog also fails).
>i don't know if this is a bug in reiserfsck....and maybe there is a way to insert a journal into between the rootblock and the superblock (where the journal was before the crash...)?
>
>thanks, thomas.
>
>
>
bad/misconfigured hardware consequences (and recovering from them) are 
handled by www.namesys.com/support.html, or by users on the mailing 
list.   The more people who go to www.namesys.com/support.html, the more 
I can afford to have Vitaly improve fsck....

Hans

Re: journal size==0 [reiserfs 3.6, reiserutils 3.x.1b]

[Oleg Drokin]

Hello!

On Mon, Apr 15, 2002 at 12:26:51AM +0200, Thomas Wiedemann wrote:

> i cannot mount my reiserfs partition any more, because of that:
> super-459: read_super_block: super found at block 16 is within its own log. It must not be of this format type.

What kernel version do you have?
Relocated/nonstandard journal support is only available in 2.5 kernel series
for now.

> so, here's the story how i "created" this error and some details:
> due a hardware failure (the harddisk?), i got some weird error messages:
> Apr 13 17:32:13 hq kernel: hdb: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> Apr 13 17:32:13 hq kernel: hdb: dma_intr: error=0x84 { DriveStatusError BadCRC }
> (...)
There are bad hardware for sure. BAd hardware is dealt with on a special basis
described in http://namesys.com/support.html, as Hans outlined already.

Bye,
    Oleg 

Re: journal size==0 [reiserfs 3.6, reiserutils 3.x.1b]

[twist]

On Mon, 15 Apr 2002 09:21:05 +0400
Oleg Drokin <green@namesys.com> wrote:

> Hello!
> 
> On Mon, Apr 15, 2002 at 12:26:51AM +0200, Thomas Wiedemann wrote:
> 
> > i cannot mount my reiserfs partition any more, because of that:
> > super-459: read_super_block: super found at block 16 is within its own log. It must not be of this format type.
> 
> What kernel version do you have?
> Relocated/nonstandard journal support is only available in 2.5 kernel series
> for now.

2.4.18-rc4
ok, then i'll try it with the development kernel later.


> 
> > so, here's the story how i "created" this error and some details:
> > due a hardware failure (the harddisk?), i got some weird error messages:
> > Apr 13 17:32:13 hq kernel: hdb: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> > Apr 13 17:32:13 hq kernel: hdb: dma_intr: error=0x84 { DriveStatusError BadCRC }
> > (...)
> There are bad hardware for sure. BAd hardware is dealt with on a special basis
> described in http://namesys.com/support.html, as Hans outlined already.

of course it was a hardware failure that created the whole mess, but that is not my problem...i just missed a warning or something that reiserfsck --no-journal-available deletes the journal and doesn't create a new one, if the kernel it is used on does not support external journals. it failed with just using --rebuild-sb, so i tried it that way. and there is no way to tell fsck that the journal should just be ignored, right?

thnx, thomas



--
"Windows is the most documented operating system that has ever been."

--Bill Gates

Re: journal size==0 [reiserfs 3.6, reiserutils 3.x.1b]

[twist]

On Mon, 15 Apr 2002 03:48:45 +0400
Hans Reiser <reiser@namesys.com> wrote:

> Thomas Wiedemann wrote:
> 
> >hi reiserfs-developers,
> >
> >i cannot mount my reiserfs partition any more, because of that:
> >
> >super-459: read_super_block: super found at block 16 is within its own log. It must not be of this format type.
> >
> >
> >so, here's the story how i "created" this error and some details:
> >
> >due a hardware failure (the harddisk?), i got some weird error messages:
> >
> >Apr 13 17:32:13 hq kernel: hdb: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> >Apr 13 17:32:13 hq kernel: hdb: dma_intr: error=0x84 { DriveStatusError BadCRC }
> >(...)
> >
> >followed by some filesystem errors:
> >
> >Apr 13 17:33:46 hq kernel: is_tree_node: node level 432 does not match to the expected one 1
> >Apr 13 17:33:46 hq kernel: vs-5150: search_by_key: invalid format found in block 19232. Fsck?
> >Apr 13 17:33:46 hq kernel: vs-13070: reiserfs_read_inode2: i/o failure occurred trying to find stat data of [1584 1590 0x0
> > SD]
> >...and so on....
> >
> >i had to reboot my pc, the disk was ok, but the partition was dead.
> >so i downloaded the newest reiserfs-utils (3.x.1b) and tried to repair it.
> >the superblock seemed to be screwed up, so...
> >
> ># reiserfsck /dev/hdb1 --rebuild-sb --no-journal-available
> ># reiserfsck --rebuild-tree
> >
> >...did some work on the filesystem, but i'm still not able to mount it, because while rebuilding the superblock, fsck did not make a journal on the device:
> >
> ># debugreiserfs /dev/hdb1
> >
> ><-------------debugreiserfs, 2002------------->
> >reiserfsprogs 3.x.1b
> >
> >
> >Filesystem state: consistent
> >
> >Reiserfs super block in block 16 on 0x341 of format 3.6 with standard journal
> >Count of blocks on the device: 11273605
> >Number of bitmaps: 345
> >Blocksize: 4096
> >Free blocks (count of blocks - used [journal, bitmaps, data, reserved] blocks): 1611835
> >Root block: 431
> >Filesystem is cleanly umounted
> >Tree height: 5
> >Hash function used to sort names: "r5"
> >Objectid map size 972, max 972
> >Journal parameters:
> >        Device [0x0]
> >        Magic [0x0]
> >        Size 1 blocks (including 1 for journal header) (first block 0)
> >        Max transaction length 0 blocks
> >        Max batch size 0 blocks
> >        Max commit age 0
> >Blocks reserved by journal: 0
> >Fs state field: 0x0
> >sb_version: 2
> >inode generation number: 0
> >UUID: c0ce572a-1ed0-4827-b72a-8aef5cdb2015
> >LABEL: 
> >Set flags in SB:
> >
> >
> >now, that the journal's size is only one block, mount fails, while fsck claims everything to be alright (mount -o nolog also fails).
> >i don't know if this is a bug in reiserfsck....and maybe there is a way to insert a journal into between the rootblock and the superblock (where the journal was before the crash...)?
> >
> >thanks, thomas.
> >
> >
> >
> bad/misconfigured hardware consequences (and recovering from them) are 
> handled by www.namesys.com/support.html, or by users on the mailing 
> list.   The more people who go to www.namesys.com/support.html, the more 
> I can afford to have Vitaly improve fsck....
> 
> Hans
> 

the information on this partition is not that important that i would pay money for it. i'm just a student trying to fix a harddrive, i just thought the missing journal on a 2.4 kernel and with mount -o nolog not working is something like a bug.

bye, thomas


--
"Windows is the most documented operating system that has ever been."

--Bill Gates