recovery of crashed reiserfs disk?

recovery of crashed reiserfs disk?

[Francois-Rene Rideau]

Dear ReiserFS developers,

I have at home a reiserfs partition that seems to be corrupted,
on a physically damaged disk.
I would like to know if there's any chance of either my recovering any
data, or if I'd better send the disk back for replacement immediately.
(I have backups for most but not all of my data).

* Here is what I get when the kernel tries to mount the root partition
 at bootup:
------>8------>8------>8------>8------>8------>8------>8------>8------>8------
hda: read_intr: error=0x40 { UncorrectableError }, LBAsect=223035648, sector=204472320
end_request: I/O error, dev 03:04 (hda), sector 204472320
hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
hda: read_intr: error=0x40 { UncorrectableError }, LBAsect=227754240, sector=209190912
end_request: I/O error, dev 03:04 (hda), sector 209190912
sh-2029: reiserfs read_bitmaps: bitmap block (#15630336) reading failed
reiserfs_read_super: unable to read bitmap
hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
hda: read_intr: error=0x01 { AddrMarkNotFound }, LBAsect=230637824, sector=212074496
hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
hda: read_intr: error=0x01 { AddrMarkNotFound }, LBAsect=230637824, sector=212074496
hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
hda: read_intr: error=0x40 { UncorrectableError }, LBAsect=230637824, sector=212074496
end_request: I/O error, dev 03:04 (hda), sector 212074496
hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
hda: read_intr: error=0x40 { UncorrectableError }, LBAsect=235880704, sector=217317376
end_request: I/O error, dev 03:04 (hda), sector 217317376
Kernel panic: VFS: Unable to mount root fs on 03:04
------>8------>8------>8------>8------>8------>8------>8------>8------>8------
 All in all something like 14 I/O error series of message clutter appear,
 for something like 3 screen fulls. The first error message is a block read
 error for a sector at LBA sector 143606016, and it goes on and on with
 other blocks failing to be read, until that final series of messages.

More information:
* the 120MB disk was used on my old P75 server, which was feeling slow for
 many applications. I took an opportunity to upgrade it to a PII-350, and
 decided to physically move the disk to the new server (after configuring
 GRUB to default to a kernel adapted to the new hardware).
 It seems that the disk got too hot and crashed at some point,
 probably after shutting it down at this very time
 and moving it to a new case while it was still very hot.
 In any case, another disk died prematurely and completely when placed
 at the same place in the same machine, one year ago -- probably due
 to heat and stress. This heat was also one of the reasons that prompted
 me to upgrade the hardware. Should have done so earlier. Doh.
 
* I tried to inspect the disk from my workstation, to see what I could
 salvage. Thanks to IDE racks, I can easily use the disk as /dev/hdc.
 Below is some information about its configuration.

* In the old machine, the old BIOS forced me to partition it using C/H/S
 geometry 238216/16/63 instead of the usual LBA 14946/255/63 that is used
 on a similar disk in my workstation. The disk was partitioned as follows
------>8------>8------>8------>8------>8------>8------>8------>8------>8------
Disk /dev/hdc: 122.9 GB, 122942324736 bytes
16 heads, 63 sectors/track, 238216 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes

   Device Boot    Start       End    Blocks   Id  System
/dev/hdc1             1       130     65488+  83  Linux
/dev/hdc2           131     16384   8192016   83  Linux
/dev/hdc3         16385     18416   1024128   82  Linux swap
/dev/hdc4         18417    238216 110779200   83  Linux
------>8------>8------>8------>8------>8------>8------>8------>8------>8------

* hda4 is the rootfs, hda1 is /boot -- both reiserfs.
 hda2 is spare, and hda3 is swap.

* /dev/hda1 works perfectly (but doesn't contain much information,
 besides the kernel and boot configuration).

* reiserfsck -a /dev/hdc4 reports:
------>8------>8------>8------>8------>8------>8------>8------>8------>8------
Reiserfs super block in block 16 on 0x1604 of format 3.6 with standard journal
Blocks (total/free): 27694800/15423590 by 4096 bytes
Filesystem is cleanly umounted
------>8------>8------>8------>8------>8------>8------>8------>8------>8------

* reiserfsck /dev/hdc4 screams the following:
------>8------>8------>8------>8------>8------>8------>8------>8------>8------
<--------reiserfsck 3.6.4, 2002-------->

Will read-only check consistency of the filesystem on /dev/hdc4
Will put log info to 'stdout'

Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes
###########
reiserfsck --check started at Fri Jan 17 19:47:07 2003
###########

The problem has occurred looks like a hardware problem.
Check your hard drive for badblocks.

bread: Cannot read the block (15630336).

zsh: 980 abort      reiserfsck /dev/hdc4
------>8------>8------>8------>8------>8------>8------>8------>8------>8------

* Indeed, if reiserfs is counting 4096-byte blocks, then 15630336 matches
 LBA sector 143606016 (the first in the kernel error log), and
	dd if=/dev/hdc of=/dev/zero count=1 skip=143606016
 reports an error, and so do nearby sectors from ...007 to ...023 (whereas
 for instance the last sector in partition is 221558399 and works perfectly).
 Ouch.

* I was distracted for some time, because according to the suggestion
 of reiserfs, I tried badblocks for the whole disk:
  badblocks -o bad.hdc -b 512 -c 1024 /dev/hdc
 But it reported no error. I then tried just for the detected bad sector:
  badblocks -o bad.hdc -b 512 -c 1 /dev/hdc 143606020 143606010
 It still reported no error -- useless program!

* The disk is not quite full, and block 15630336 (60GB) is possibly beyond
 the last data written to disk. Indeed, readable blocks around that place
 seem to be consistently filled with zeros.

* So is there any chance that I may recover some data from the readable part
 of the disk?

* If mirroring the "good" part could help, I've got another 120GB disk to do
 it (that holds the backup), but all the data shuffling involved in trying is
 heavy enough (and risky for the data, too) that I don't want to try without
 hope from you -- also, if there is hope in such a thing, do you know where
 to find a program that would indeed copy all the good sectors and skip over
 the bad ones?

Thanks a lot for any answer, even just to tell me there's no hope.

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[  TUNES project for a Free Reflective Computing System  | http://tunes.org  ]
God exists and I'm His Prophet. And He says: "Don't you believe in Me or in
My Prophet, least you be doomed to go to Hell, for I gave you brains not to
believe in things dogmatically and superstitiously, but to think rationally."
		-- Faré

Re: recovery of crashed reiserfs disk?

[Ookhoi]

Francois-Rene Rideau wrote (ao):
> I have at home a reiserfs partition that seems to be corrupted,
> on a physically damaged disk.

...

> hda: read_intr: error=0x40 { UncorrectableError }, LBAsect=223035648, sector=204472320
> end_request: I/O error, dev 03:04 (hda), sector 204472320
> hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }

...

>    Device Boot    Start       End    Blocks   Id  System
> /dev/hdc4         18417    238216 110779200   83  Linux

...

> * reiserfsck /dev/hdc4 screams the following:
> <--------reiserfsck 3.6.4, 2002-------->
> 
> Will read-only check consistency of the filesystem on /dev/hdc4
> Will put log info to 'stdout'
> 
> Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes
> ###########
> reiserfsck --check started at Fri Jan 17 19:47:07 2003
> ###########
> 
> The problem has occurred looks like a hardware problem.
> Check your hard drive for badblocks.
> 
> bread: Cannot read the block (15630336).
> 
> zsh: 980 abort      reiserfsck /dev/hdc4
> 
> * Indeed, if reiserfs is counting 4096-byte blocks, then 15630336 matches
>  LBA sector 143606016 (the first in the kernel error log), and
> 	dd if=/dev/hdc of=/dev/zero count=1 skip=143606016
>  reports an error, and so do nearby sectors from ...007 to ...023 (whereas
>  for instance the last sector in partition is 221558399 and works perfectly).
>  Ouch.

...
 
> * The disk is not quite full, and block 15630336 (60GB) is possibly beyond
>  the last data written to disk. Indeed, readable blocks around that place
>  seem to be consistently filled with zeros.
> 
> * So is there any chance that I may recover some data from the readable part
>  of the disk?
> 
> * If mirroring the "good" part could help, I've got another 120GB disk to do
>  it (that holds the backup), but all the data shuffling involved in trying is
>  heavy enough (and risky for the data, too) that I don't want to try without
>  hope from you -- also, if there is hope in such a thing, do you know where
>  to find a program that would indeed copy all the good sectors and skip over
>  the bad ones?

Dunno if you got an answer already. My mail is a bit slow atm.

I think you can copy your data to the 120GB disk, reiserfsck it, and
mount it. 

You can dd /dev/hdc4 with 

dd if=/dev/hdc4 of=/largedir/largefile conv=noerror

where /largedir is a directory on another disk.

If that doesn't work, you could try ddrescue:
http://www.garloff.de/kurt/linux/ddrescue/

After you created an image, attach it to a loop device, reiserfsck it,
mount it and hopefully recover your data.

Hope that helps.

Re: recovery of crashed reiserfs disk?

[Oleg Drokin]

Hello!

On Sat, Jan 18, 2003 at 08:09:41AM +0100, Ookhoi wrote:

> Dunno if you got an answer already. My mail is a bit slow atm.
> I think you can copy your data to the 120GB disk, reiserfsck it, and
> mount it. 
> You can dd /dev/hdc4 with 
> dd if=/dev/hdc4 of=/largedir/largefile conv=noerror
> where /largedir is a directory on another disk.

This is only partly true.
We found that only conv=noerror produces HDD images with
bad sectors siply skipped. This is not acceptable.
You need to use dd_rescue tool that is developed at SuSE I think.

> If that doesn't work, you could try ddrescue:
> http://www.garloff.de/kurt/linux/ddrescue/

In fact don't even try plain dd ;)

Bye,
    Oleg

Re: recovery of crashed reiserfs disk?

[Ookhoi]

Hi Oleg,

Oleg Drokin wrote (ao):
> On Sat, Jan 18, 2003 at 08:09:41AM +0100, Ookhoi wrote:
> > Dunno if you got an answer already. My mail is a bit slow atm.
> > I think you can copy your data to the 120GB disk, reiserfsck it, and
> > mount it. 
> > You can dd /dev/hdc4 with 
> > dd if=/dev/hdc4 of=/largedir/largefile conv=noerror
> > where /largedir is a directory on another disk.
> 
> This is only partly true.
> We found that only conv=noerror produces HDD images with
> bad sectors siply skipped. This is not acceptable.
> You need to use dd_rescue tool that is developed at SuSE I think.
> 
> > If that doesn't work, you could try ddrescue:
> > http://www.garloff.de/kurt/linux/ddrescue/
> 
> In fact don't even try plain dd ;)

Thank you for the correction. Can you please consider to add these tips
to the faq?

Re: recovery of crashed reiserfs disk?

[Francois-Rene Rideau]

Thanks a lot to all those who responded.

I'll try that dd_rescue utility as soon as I have fully backed up
my current data to CDs, and tell you how well it went.

> http://www.garloff.de/kurt/linux/ddrescue/

As a wishlist item, to emulate the same effect without requiring another
same-sized disk, maybe there could be an option to mount reiserfs read-only
while considering read-errors as blank sectors?

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[  TUNES project for a Free Reflective Computing System  | http://tunes.org  ]
"Lisp is a programmable programming language." -- John Foderaro

Re: recovery of crashed reiserfs disk?

[Francois-Rene Rideau]

Kisses to you all! dd_rescue did save the day indeed!
And thanks to the -a option (sparse image), I didn't even have to
empty my other disk completely before to recover data.

/usr/src/local/dd_rescue/dd_rescue -b 32768 -B 512 -l dd_rescue.log -a -v /dev/hdc4 hdc4.img
mount -o loop -r hdc4.img /mnt -t reiserfs

(However I persist that such an operation would be unnecessary
if reiserfs -- and maybe linux in general -- had an option to mount
a block device readonly with error == blank).

>> http://www.garloff.de/kurt/linux/ddrescue/

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[  TUNES project for a Free Reflective Computing System  | http://tunes.org  ]
God exists and I'm His Prophet. And He says: "Don't you believe in Me or in
My Prophet, least you be doomed to go to Hell, for I gave you brains not to
believe in things dogmatically and superstitiously, but to think rationally."
		-- Faré

Crash again!

[Francois-Rene Rideau]

After the hardware crash, the software crash!

I added RAM to my workstation and rebooted.
Big mistake: I had stopped the machine with swsusp instead of a plain halt.
By the time I realized it, it was too late.
swsusp recover failed because the RAM size didn't match.
Now the reiserfs partition is half-unmounted,
and trying to mount results in an endless loop
as reiserfs tries to replay the journal.

Is the partition recoverable? Can the data be retrieved?
Should I try reiserfsck or not?
Should I try to get swsusp to recover the same state and do its thing,
or is it too late?

Should I run to the shop where I sent my previous hardware-crashed disk
so that they don't actually send the disk back to manufacturer for exchange?

What a loser!

Thanks for your precious advice.

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[  TUNES project for a Free Reflective Computing System  | http://tunes.org  ]
Do not handicap your children by making their lives easy. -- Robert Heinlein

Re: Crash again!

[Ookhoi]

Francois-Rene Rideau wrote (ao):
> After the hardware crash, the software crash!
> 
> I added RAM to my workstation and rebooted.
> Big mistake: I had stopped the machine with swsusp instead of a plain
> halt. By the time I realized it, it was too late.
> swsusp recover failed because the RAM size didn't match.
> Now the reiserfs partition is half-unmounted,
> and trying to mount results in an endless loop
> as reiserfs tries to replay the journal.
> 
> Is the partition recoverable? Can the data be retrieved?
> Should I try reiserfsck or not?

That would be the first thing to try :-)

> Should I try to get swsusp to recover the same state and do its thing,
> or is it too late?

This will not do anything good to your filesystem.

> Should I run to the shop where I sent my previous hardware-crashed
> disk so that they don't actually send the disk back to manufacturer
> for exchange?

A shop will be of no help in this case (or at least here; the shop
people have exactly zero clue; yours could be better though). There is a
very good change that you will be able to solve this yourself. Run the
latest reiserfsck (in this case, I would run the latest -pre, as I
didn't read bad things about it on the list and it is already 7 weeks
old).

Good luck!

PS, in cases like these, I notice a nice warm feeling when I hug my
backups. You should try it too. You might never need them, but then
again, _if_ you need them, they suddenly mean much more to you than you
could have ever thought a bunch of zipped files would do.

Re: Crash again!

[Francois-Rene Rideau]

On Wed, Jan 22, 2003 at 06:57:12AM +0100, Ookhoi wrote:
>> Should I try reiserfsck or not?
> That would be the first thing to try :-)
Ok. I tried and it worked. Pphew!
Thanks a lot, once again, for saving the day!
Weird that trying to mount it got stuck with no message,
besides the fact that it was replaying journal for a read-only partition.

>> Should I run to the shop where I sent my previous hardware-crashed
>> disk so that they don't actually send the disk back to manufacturer
>> for exchange?
> A shop will be of no help in this case
OK, I didn't explain well: I had two disks, one being the backup of the other.
The first disk had hardware damage, so I went to the shop and had it sent
for exchange with the manufacturer. If I lose the second disk to a software
mishap, I ought to run to the shop and tell them to NOT send the disk back
(yet) so I can once again recover the data with dd_rescue.

> PS, in cases like these, I notice a nice warm feeling when I hug my
> backups.
Yup. Everyone should make a daily ritual prayer to Baah-Kuhp,
the God of data preservation. 
When I had the two disks, I made a daily prayer for my most precious data,
and a weekly prayer for the whole of my data.
One problem with huge disks is that backup solutions that scale
cost quite a lot, and a slow 10Mbps network is quite a slow way to do backups.

Apparently, the God took revenge that I wasn't enough of a firm believer,
so He made both of my disks fail at once, as a way to teach me a lesson.
Now I believe again.
Be thousand times blessed, oh, Baah-Kuhp, God of data preservation!
Have mercy of me! Though I am a sinner, I promise my faith will be fervent.
I will backup not just to two disks, but to tape, cdrom, remote disk,
and other means. Have mercy, oh misericordious God!

Oh, you unbelievers, open your eyes, and start praying with me!
Baah-Kuhp is a just and merciful god. He saves. He saved me. He will save you.
But he'll let you rot to hell, if you don't pray Him with fervor and regularity.

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[  TUNES project for a Free Reflective Computing System  | http://tunes.org  ]
"Don't worry about people stealing your ideas.  If your ideas are any good,
you'll have to ram them down people's throats."		-- Howard Aiken

Crash: the problem was DMA!

[Francois-Rene Rideau]

Dear reiserfs developers,

here's an update on the trouble I had lately (the second disk crash):
the culprit was IDE DMA!

Here's the story:
* I installed more RAM, and it failed, so I upgrade the BIOS to see it
 (machine was dead after I upgraded the BIOS, until I was told to also
 short the NVRAM to reset the BIOS parameters, but that's another story).
* After I rebooted, swsusp failed (oops, I had suspended the machine
 instead of halting it), and I originally attributed my troubles to that.
 The machine was thereupon blocked right after mounting its reiserfs rootfs.
* On another machine, I could reiserfsck the disk, mount it and backup
 its contents. Pphew!
* Windows and debian's linux-2.4.18-bf2.4 were working fine on the machine,
 and memtest86 reported no error, so the hardware looks OK.
* However, using any of my custom-compiled Linux kernels would result in
 miserable kernel panics while accessing the big 100G reiserfs partition:
 I ksymoops'ed a few panics, and they all as a NULL-pointer dereference
 while accessing the big reiserfs partition: open() system call or
 disk interrupt handler.
 The panic came quick enough (while in init, in rcS or getty),
 though not at a fully predictable place.
* I could put some support files in my tiny /boot, I can successfully boot
 with root=/dev/hda1 init=/bin/sash -- even with the kernels that fail
 on the big partition. Then, if I can try to reiserfsck the disk,
 I get a panic or lack thereof depending on my using a custom kernel
 or the debian-supplied one. I suppose the partition was small enough
 that timing problems didn't have the opportunity to occur.
* I started suspecting DMA thanks to a reiserfsck message telling me
 while using debian's kernel that lack of dma was detrimental to performance.
 Indeed, compiling a custom kernel w/o DMA caused the system to boot,
 while using hdparm to enable dma caused it to hang.
* The reiserfs partition seems to have survived quite well all those
 reboots and crashes that happened while sorting out this mess.
 Congratulations!
* All in all, it looks like my BIOS update hosed the way the IDE chipset
 is configured, as far as having Linux use the DMA is concerned. Darn.

This message is to tell you what I spent quite some time to figure out,
so that if the problem occurs again, you (yes, you who are asked to solve
problems, but also YOU, who have a problem and are Googling in search of
a solution to your problem, and found this message in a mailing-list archive)
can find the answer readily available.

PS: YES, my old kern.log's from before the BIOS update do show
hda: 240121728 sectors (122942 MB) w/2048KiB Cache, CHS=14946/255/63, UDMA(66)
While the newer one lack the UDMA(66).
VP_IDE: VIA vt82c686a (rev 1b) IDE UDMA66 controller on pci00:04.1
In case anyone cares, that's an ASUS K7M motherboard.
Darn. I still have this performance bug - but at least, the computer works.
Advice welcome, though it's becoming off-topic (so private message might
be more suited).

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[  TUNES project for a Free Reflective Computing System  | http://tunes.org  ]
Premature optimization is the root of all evil.
		-- D.E. Knuth

Re: Crash: the problem was DMA!

[Manuel Krause]

On 01/24/2003 11:28 PM, Francois-Rene Rideau wrote:
 > Dear reiserfs developers,
 >
 > here's an update on the trouble I had lately (the second disk crash):
 > the culprit was IDE DMA!
 >
[snip: success story && reiserfsck did a good job]
 >
 > PS: YES, my old kern.log's from before the BIOS update do show
 > hda: 240121728 sectors (122942 MB) w/2048KiB Cache, CHS=14946/255/63,
 > UDMA(66)
 > While the newer one lack the UDMA(66).
 > VP_IDE: VIA vt82c686a (rev 1b) IDE UDMA66 controller on pci00:04.1
 > In case anyone cares, that's an ASUS K7M motherboard.
 > Darn. I still have this performance bug - but at least, the
 > computer works.
 > Advice welcome, though it's becoming off-topic (so private message
 > might be more suited).

Hi!

Since I have this cheap Notebook (Clevo 8500V, Taiwan) I've been
fiddling to work around the buggy chipset and/or the buggy BIOS.

I have a
    VP_IDE: VIA vt82c686a (rev 22) IDE UDMA66 controller on pci00:07.1

and @ ide0:
    hda: 39070080 sectors (20004 MB) w/2048KiB Cache, CHS=2432/255/63,
         UDMA(66)
@ ide1:
    hdd: 35433216 sectors (18142 MB) w/418KiB Cache, CHS=35152/16/63,
         UDMA(66)
    hdc: ATAPI 24X DVD-ROM drive, 128kB Cache, UDMA(33)

BIOS settings do not have an effect to my disk configuration under
Linux. Under Win98 I get severe transfer timeouts when hdc has a wrong
(increased) UDMA setting in the BIOS.

I mainly use the following to configure my chipset/disks under Linux:
* Kernel: append = ide0=ata66 ide1=ata66 [...]
           config: CONFIG_BLK_DEV_VIA82CXXX=y
                   and the DMA related stuff, of course.
* hdparm @bootup:  -qB255qS0qW1qa16qd1qu1qK1qk1qX68 /dev/hda
                    -...                      ...X67 /dev/hdd
                    -qa16qd1qu1qK1qk1qX67 /dev/hdc
    (I know each of them is over-tuned in -X by at least  1 ...
     but so the hardware or kernel based max. settings stay on.
     If I issued values according to and higher than the max.
     rate I get "... not functional" errors but the original
     values remain)
   --> see ftp://sunsite.unc.edu/pub/Linux/system/hardware/ for
       the latest release of hdparm)
* powertweak settings
   --> http://powertweak.sourceforge.net/

(Some of the settings may be outdated by now, I've kept them "in
tradition". Oh, yes, and they may be dangerous!!! Backups...)

"cat /proc/ide/via" gives me some hints if I really misconfigured
something but it doesn't show real conditions concerning the transfer
rate.

I tried many ways to adjust the parameters in former times to get equal
rates for hda and hdd for testing purposes. But the transfer rate
relation between hda and hdd (based on "hdparm -t /dev/drivename" and
real world ReiserFS copy sessions) _always_ stays between 1.3 and 1.45 .


Maybe one setting shown above could at least release your machines
general performance.


Best wishes and happy testing,

Manuel

mkreiserfs -s 1024 makes unmountable partitions

[Francois-Rene Rideau]

Hi! No hard disk crash today (I'm just disabling the DMA )-" )
However, I've tried to make small reiserfs partitions,
and was annoyed at the journal taking a significant size of the disk:
32MB is 50% of my 64MB /boot partition, and 40% of the whole
of my server's 80MB harddisk.

I saw that mkreiserfs had an option -s to select the size of the journal,
and tried to use it to make a 4MB journal:
	mkreiserfs -s 1024 /dev/hdc1
However, whereas mkreiserfs didn't complain, the resulting partition
was unmountable by linux. In the syslogs, the kernel complains:
read_super_block: can't find a reiserfs filesystem on (dev 16:01, block 128, size 512)
read_super_block: can't find a reiserfs filesystem on (dev 16:01, block 16, size 512)

I there a way to make a reiserfs partition with a small journal?
32MB is really a waste, on some partitions.
Would a small kernel patch do it?
In any case, I think that it is a bug that mkreiserfs doesn't check
the consistency of its parameters with what the kernel is able to handle.

PS: I'm using debian's reiserfsprogs 1:3.6.4-2 and linux kernel 2.4.20.

Cheers!

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[  TUNES project for a Free Reflective Computing System  | http://tunes.org  ]
You can only find happiness by striving towards something else.

Re: mkreiserfs -s 1024 makes unmountable partitions

[Ookhoi]

Francois-Rene Rideau wrote (ao):
> Hi! No hard disk crash today (I'm just disabling the DMA )-" )
> However, I've tried to make small reiserfs partitions,
> and was annoyed at the journal taking a significant size of the disk:
> 32MB is 50% of my 64MB /boot partition, and 40% of the whole
> of my server's 80MB harddisk.

I would not make more than one partition on a 80MB harddisk.

When I cleaned my room I found an old IBM 386 with a 150MB harddisk and
6MB ram. I think I put ext2 on it as it has less cpu overhead. It will
be a terminal anyway so I don't care about filechecks (a pitty I won't
be able to use a ramdisk).

Yours might be old too. Maybe ext2 is a better option?
(Don't worry, I have reiserfs on all my other systems ;-)

> I saw that mkreiserfs had an option -s to select the size of the journal,
> and tried to use it to make a 4MB journal:
> 	mkreiserfs -s 1024 /dev/hdc1
> However, whereas mkreiserfs didn't complain, the resulting partition
> was unmountable by linux. In the syslogs, the kernel complains:
> read_super_block: can't find a reiserfs filesystem on (dev 16:01, block 128, size 512)
> read_super_block: can't find a reiserfs filesystem on (dev 16:01, block 16, size 512)
> 
> I there a way to make a reiserfs partition with a small journal?
> 32MB is really a waste, on some partitions. Would a small kernel
> patch do it? In any case, I think that it is a bug that mkreiserfs
> doesn't check the consistency of its parameters with what the kernel
> is able to handle.

According to the manpage it should work:
-s | --journal-size N
 N is size of journal in blocks. When journal is to be on a separate
 device - its size defaults to number of blocks that device has. When
 journal is to be on a host device - its size defaults 8193 and maximal
 possible value is 32749 (for blocksize 4k). Minimun is 513 for both
 cases.

I've played with it a bit. It seems it never can mount if I did
mkreiserfs with the -s option (1024, 2048, 8193 (default), 10240). I can
if I mkreiserfs without -s (or others).

> PS: I'm using debian's reiserfsprogs 1:3.6.4-2 and linux kernel 2.4.20.

reiserfsprogs 3.6.5-pre1 and 2.4.18-rc4

Re: mkreiserfs -s 1024 makes unmountable partitions

[Brian Tinsley]

>
>
>According to the manpage it should work:
>-s | --journal-size N
> N is size of journal in blocks. When journal is to be on a separate
> device - its size defaults to number of blocks that device has. When
> journal is to be on a host device - its size defaults 8193 and maximal
> possible value is 32749 (for blocksize 4k). Minimun is 513 for both
> cases.
>
>I've played with it a bit. It seems it never can mount if I did
>mkreiserfs with the -s option (1024, 2048, 8193 (default), 10240). I can
>if I mkreiserfs without -s (or others).
>  
>

It seems like I've done this before. I want to say that it requires some 
kernel patches, but at the moment I cannot remember. Perhaps Chris  M. 
or Oleg can refresh my memory :)

Re: mkreiserfs -s 1024 makes unmountable partitions

[Oleg Drokin]

Hello!

On Sun, Jan 26, 2003 at 07:18:16PM +0100, Francois-Rene Rideau wrote:

> Hi! No hard disk crash today (I'm just disabling the DMA )-" )
> However, I've tried to make small reiserfs partitions,
> and was annoyed at the journal taking a significant size of the disk:
> 32MB is 50% of my 64MB /boot partition, and 40% of the whole
> of my server's 80MB harddisk.
> I saw that mkreiserfs had an option -s to select the size of the journal,
> and tried to use it to make a 4MB journal:
> 	mkreiserfs -s 1024 /dev/hdc1
> However, whereas mkreiserfs didn't complain, the resulting partition
> was unmountable by linux. In the syslogs, the kernel complains:
> read_super_block: can't find a reiserfs filesystem on (dev 16:01, block 128, size 512)
> read_super_block: can't find a reiserfs filesystem on (dev 16:01, block 16, size 512)

You need journal relocation patches from Chris Mason.
ftp://ftp.suse.com/pub/people/mason/patches/datalogging

> I there a way to make a reiserfs partition with a small journal?

Sure. You just did it. ;)
Not you need in-kernel support to be able to mount it.
Ir You can use 2.5 kernels (note these are not recommended for productional environment
of course)

> Would a small kernel patch do it?

Sure.

> In any case, I think that it is a bug that mkreiserfs doesn't check
> the consistency of its parameters with what the kernel is able to handle.

No, that's not a bug. mkreiserfs cannot know if you are just making a filesystem
and planning to reboot into proper kernel later (or even move the disk to other system).
Also it cannot detect if your current kernel have any patches applied or not.

Bye,
    Oleg

Re: mkreiserfs -s 1024 makes unmountable partitions

[Scott R. Every]

this URL works better:
 ftp://ftp.suse.com/pub/people/mason/patches/data-logging

Oleg, thanks so much for this info(and Chris, thanks for the patches). 
This is much needed for embedded filesystems of 128MB and smaller.  Its 
hard to fit a 32MB journal on a 32 or 16MB FLASH disk!

s

--On Monday, January 27, 2003 9:59 AM +0300 Oleg Drokin <green@namesys.com> 
wrote:

> Hello!
>
> On Sun, Jan 26, 2003 at 07:18:16PM +0100, Francois-Rene Rideau wrote:
>
>> Hi! No hard disk crash today (I'm just disabling the DMA )-" )
>> However, I've tried to make small reiserfs partitions,
>> and was annoyed at the journal taking a significant size of the disk:
>> 32MB is 50% of my 64MB /boot partition, and 40% of the whole
>> of my server's 80MB harddisk.
>> I saw that mkreiserfs had an option -s to select the size of the journal,
>> and tried to use it to make a 4MB journal:
>> 	mkreiserfs -s 1024 /dev/hdc1
>> However, whereas mkreiserfs didn't complain, the resulting partition
>> was unmountable by linux. In the syslogs, the kernel complains:
>> read_super_block: can't find a reiserfs filesystem on (dev 16:01, block
>> 128, size 512) read_super_block: can't find a reiserfs filesystem on
>> (dev 16:01, block 16, size 512)
>
> You need journal relocation patches from Chris Mason.
> ftp://ftp.suse.com/pub/people/mason/patches/datalogging
>
>> I there a way to make a reiserfs partition with a small journal?
>
> Sure. You just did it. ;)
> Not you need in-kernel support to be able to mount it.
> Ir You can use 2.5 kernels (note these are not recommended for
> productional environment of course)
>
>> Would a small kernel patch do it?
>
> Sure.
>
>> In any case, I think that it is a bug that mkreiserfs doesn't check
>> the consistency of its parameters with what the kernel is able to handle.
>
> No, that's not a bug. mkreiserfs cannot know if you are just making a
> filesystem and planning to reboot into proper kernel later (or even move
> the disk to other system). Also it cannot detect if your current kernel
> have any patches applied or not.
>
> Bye,
>     Oleg

Re: mkreiserfs -s 1024 makes unmountable partitions

[Oleg Drokin]

Hello!

On Mon, Jan 27, 2003 at 02:20:47AM -0500, Scott R. Every wrote:
> this URL works better:
> ftp://ftp.suse.com/pub/people/mason/patches/data-logging
> Oleg, thanks so much for this info(and Chris, thanks for the patches). 
> This is much needed for embedded filesystems of 128MB and smaller.  Its 
> hard to fit a 32MB journal on a 32 or 16MB FLASH disk!

Actually if you have direct access to FLASH device (e.g. through MTD),
then you really want to look at jffs2. Besides being journalled, it also
provides data compression (which is invaluable for such small storage sizes)
and flash wearing control (or what is the name for facility that controls that
certain areas of flash are not written to more often then other ones).

Bye,
    Oleg

Re: mkreiserfs -s 1024 makes unmountable partitions

[Scott R. Every]

Using MTD and will check out jffs2, but I am also accessing CF cards thru 
yenta socket.  Would reiserfs or jffs2 be more appropriate for CF cards?

Again, thanks!

s

--On Monday, January 27, 2003 10:25 AM +0300 Oleg Drokin 
<green@namesys.com> wrote:

> Hello!
>
> On Mon, Jan 27, 2003 at 02:20:47AM -0500, Scott R. Every wrote:
>> this URL works better:
>> ftp://ftp.suse.com/pub/people/mason/patches/data-logging
>> Oleg, thanks so much for this info(and Chris, thanks for the patches).
>> This is much needed for embedded filesystems of 128MB and smaller.  Its
>> hard to fit a 32MB journal on a 32 or 16MB FLASH disk!
>
> Actually if you have direct access to FLASH device (e.g. through MTD),
> then you really want to look at jffs2. Besides being journalled, it also
> provides data compression (which is invaluable for such small storage
> sizes) and flash wearing control (or what is the name for facility that
> controls that certain areas of flash are not written to more often then
> other ones).
>
> Bye,
>     Oleg

Re: mkreiserfs -s 1024 makes unmountable partitions

[Oleg Drokin]

Hello!

On Mon, Jan 27, 2003 at 02:37:36AM -0500, Scott R. Every wrote:
> Using MTD and will check out jffs2, but I am also accessing CF cards thru 
> yenta socket.  Would reiserfs or jffs2 be more appropriate for CF cards?

Though there is MTD emulation for block devices, CF cards usually have their
own wear levelling control. On the other hand reiserfs does not offer
data-compression (yet?). Decision is all yours anyway.

Bye,
    Oleg

Re: mkreiserfs -s 1024 makes unmountable partitions

[Hans Reiser]

Oleg Drokin wrote:

>Hello!
>
>On Mon, Jan 27, 2003 at 02:20:47AM -0500, Scott R. Every wrote:
>  
>
>>this URL works better:
>>ftp://ftp.suse.com/pub/people/mason/patches/data-logging
>>Oleg, thanks so much for this info(and Chris, thanks for the patches). 
>>This is much needed for embedded filesystems of 128MB and smaller.  Its 
>>hard to fit a 32MB journal on a 32 or 16MB FLASH disk!
>>    
>>
>
>Actually if you have direct access to FLASH device (e.g. through MTD),
>then you really want to look at jffs2. Besides being journalled, it also
>provides data compression (which is invaluable for such small storage sizes)
>and flash wearing control (or what is the name for facility that controls that
>certain areas of flash are not written to more often then other ones).
>
>Bye,
>    Oleg
>
>
>  
>
Reiser4 will provide compression (compression plugin is being coded 
now), and won't waste space for a mandatory fixed size journal area.

-- 
Hans

Re: mkreiserfs -s 1024 makes unmountable partitions

[Francois-Rene Rideau]

On Mon, Jan 27, 2003 at 09:59:57AM +0300, Oleg Drokin wrote:
> ftp://ftp.suse.com/pub/people/mason/patches/data-logging
Thanks for the tip. Can you tell me which patches are needed?

>> In any case, I think that it is a bug that mkreiserfs doesn't check
>> the consistency of its parameters with what the kernel is able to handle.
> No, that's not a bug. mkreiserfs cannot know if you are just making
> a filesystem and planning to reboot into proper kernel later
> (or even move the disk to other system).
> Also it cannot detect if your current kernel have any patches applied or not.
Well, it could detect that the kernel version is under some version, issue
a Warning that a patch is required wrt vanilla kernel of same version, and
give a pointer to said patch -- that would completely solve the issue with
newbies like me asking you this question.

Thanks a lot for the support!

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[  TUNES project for a Free Reflective Computing System  | http://tunes.org  ]
A programming language is low level
when its programs require attention to the irrelevant.
	-- Alan Perlis

Re: mkreiserfs -s 1024 makes unmountable partitions

[Oleg Drokin]

Hello!

On Mon, Jan 27, 2003 at 12:26:51PM +0100, Francois-Rene Rideau wrote:
> > ftp://ftp.suse.com/pub/people/mason/patches/data-logging
> Thanks for the tip. Can you tell me which patches are needed?

01-relocation-5.diff.gz is the one.

> >> In any case, I think that it is a bug that mkreiserfs doesn't check
> >> the consistency of its parameters with what the kernel is able to handle.
> > No, that's not a bug. mkreiserfs cannot know if you are just making
> > a filesystem and planning to reboot into proper kernel later
> > (or even move the disk to other system).
> > Also it cannot detect if your current kernel have any patches applied or not.
> Well, it could detect that the kernel version is under some version, issue
> a Warning that a patch is required wrt vanilla kernel of same version, and

Well. But given the trend that lots of users are using distro kernels only,
and e.g. SuSE ships these patches for some time already, such a warning
will cause lots of confusion.

> give a pointer to said patch -- that would completely solve the issue with
> newbies like me asking you this question.

So far we have not found any good way to print warning only when it is really needed.
Always printing the warning is not very good idea in my opinion.

Bye,
    Oleg

Re: mkreiserfs -s 1024 makes unmountable partitions

[Francois-Rene Rideau]

On Mon, Jan 27, 2003 at 02:33:05PM +0300, Oleg Drokin wrote:
> But given the trend that lots of users are using distro kernels only,
> and e.g. SuSE ships these patches for some time already, such a warning
> will cause lots of confusion.
Hum. Then maybe SuSE could also patch back the mkreiserfs to not produce
a warning? And/or you could and a note in the man page that would explain
things better than a warning could -- the man page is the first thing one
reads in case of trouble. Anyway.

> So far we have not found any good way to print warning only
> when it is really needed.
> Always printing the warning is not very good idea in my opinion.
I understand that.

Cheers!

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[  TUNES project for a Free Reflective Computing System  | http://tunes.org  ]
If Java had true garbage collection, most programs would delete themselves
upon execution. -- Robert Sewell

Re: mkreiserfs -s 1024 makes unmountable partitions

[Francois-Rene Rideau]

On Mon, Jan 27, 2003 at 02:33:05PM +0300, Oleg Drokin wrote:
>>> ftp://ftp.suse.com/pub/people/mason/patches/data-logging
>> Thanks for the tip. Can you tell me which patches are needed?
> 01-relocation-5.diff.gz is the one.
Darn, it doesn't quite apply to the vanilla 2.4.20 kernel. Oh well.
Is there a patch for 2.4.20 that does it?
Or maybe a recent 2.4 reiserfs tree ready to use?
I understand I'm being annoying for not much.
Well, maybe I'll just use ext3 for these small partitions.
Anyway, thanks for all the tips.

Cheers!

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[  TUNES project for a Free Reflective Computing System  | http://tunes.org  ]
Anarchism is founded on the observation that since few men are wise enough
to rule themselves, even fewer are wise enough to rule others. -- Edward Abbey

Re: mkreiserfs -s 1024 makes unmountable partitions

[Manuel Krause]

On 01/27/2003 01:46 PM, Francois-Rene Rideau wrote:
> On Mon, Jan 27, 2003 at 02:33:05PM +0300, Oleg Drokin wrote:
> 
>>>>ftp://ftp.suse.com/pub/people/mason/patches/data-logging
>>>
>>>Thanks for the tip. Can you tell me which patches are needed?
>>
>>01-relocation-5.diff.gz is the one.
> 
> Darn, it doesn't quite apply to the vanilla 2.4.20 kernel. Oh well.
> Is there a patch for 2.4.20 that does it?
> Or maybe a recent 2.4 reiserfs tree ready to use?
> I understand I'm being annoying for not much.
> Well, maybe I'll just use ext3 for these small partitions.
> Anyway, thanks for all the tips.
> 
> Cheers!
> 

Hi!

I hope you used
ftp://ftp.suse.com/pub/people/mason/patches/data-logging/2.4.20/01-relocation-5.diff.gz

If you follow Chris Masons style and make up a link called "b" from your 
"linux" directory in the kernel src dir it applies well on a plain 
2.4.20 from kernel.org. (And I always thought that to be called 
"vanilla"...)

Manuel

Oh no! Not again!

[Francois-Rene Rideau]

Dear all,

to determine whether my DMA problem was due to the disk or the motherboard,
I moved the disk to another machine, where I could successfully
hdparm -Tt /dev/hdc without crashing linux while in udma2.
However, when I put the disk back into its rightful place,
linux died horribly with lots of error messages from reiserfs.
I booted on /boot where I had kept a minimal runtime, and used reiserfsck.
Reiserfsck reported an inconsistency that required using --rebuild-tree.
And after approximately two hours, reiserfsck --rebuild-tree entered
an endless loop, printing
do_pass_2: The block (27179935) is in the tree already. Should not happen.

Is there anything I can do about that, to put it in working order,
or should I reformat and restore what I can from backup?

I've got a distinct feeling this disk will soon go back to MAXTOR,
just like its twin brother.

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[  TUNES project for a Free Reflective Computing System  | http://tunes.org  ]
http://Bastiat.org/ - debunking economic sophisms since 1845.

Re: Oh no! Not again!

[Vitaly Fertman]

On Tuesday 28 January 2003 05:41, Francois-Rene Rideau wrote:
> Dear all,
>
> to determine whether my DMA problem was due to the disk or the motherboard,
> I moved the disk to another machine, where I could successfully
> hdparm -Tt /dev/hdc without crashing linux while in udma2.
> However, when I put the disk back into its rightful place,
> linux died horribly with lots of error messages from reiserfs.
> I booted on /boot where I had kept a minimal runtime, and used reiserfsck.
> Reiserfsck reported an inconsistency that required using --rebuild-tree.
> And after approximately two hours, reiserfsck --rebuild-tree entered
> an endless loop, printing
> do_pass_2: The block (27179935) is in the tree already. Should not happen.

looks like progs were compiled with other libs. Could you rebuild progs where 
you booted again or link them statically: 
	make LDFLAGS='-static'
and try agan.

> Is there anything I can do about that, to put it in working order,
> or should I reformat and restore what I can from backup?
>
> I've got a distinct feeling this disk will soon go back to MAXTOR,
> just like its twin brother.
>
> [ François-René ÐVB Rideau | Reflection&Cybernethics |
> http://fare.tunes.org ] [  TUNES project for a Free Reflective Computing
> System  | http://tunes.org  ] http://Bastiat.org/ - debunking economic
> sophisms since 1845.

-- 

Thanks,
Vitaly Fertman

Re: Oh no! Not again!

[Francois-Rene Rideau]

OK. So I built the latest reiserfsck as a static binary,
and ran it with --rebuild-tree, and I got an infinite loop
just like previously. In case anyone cares, I have kept the logfile for it.
Is there anything that interests you about that failure,
or should I promptly reformat the disk?

Also, does any of you have any hint as to how to identify the failure
that led to this crash? I suspect either the disk or the motherboard,
but it's hard to tell: booting on my 80MB rescue disk works well,
whereas the disk looks like it works correctly on another machine,
and does not issue errors even on that machine, if I don't use DMA.
Really weird. What scares me is that if I don't identify the problem,
a similar crash may happen again...

Cheers!

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[  TUNES project for a Free Reflective Computing System  | http://tunes.org  ]
Demand the establishment of the government in its rightful home at Disneyland.

Re: Oh no! Not again!

[Vitaly Fertman]

On Wednesday 29 January 2003 22:31, Francois-Rene Rideau wrote:
> OK. So I built the latest reiserfsck as a static binary,
> and ran it with --rebuild-tree, and I got an infinite loop
> just like previously. In case anyone cares, I have kept the logfile for it.
> Is there anything that interests you about that failure,
> or should I promptly reformat the disk?

Did you run the fsck (booted from /boot) when the drive was in that other
mashine you had no problem with or in the problem one? It is a bad idea to 
run reiserfsck on a broken hardware - the result is unpredictable. 

> Also, does any of you have any hint as to how to identify the failure
> that led to this crash? I suspect either the disk or the motherboard,

If you do not see any problem with the disk when you put it into another 
computer - it is not the disk. It can be IDE controller, cable...

> but it's hard to tell: booting on my 80MB rescue disk works well,
> whereas the disk looks like it works correctly on another machine,
> and does not issue errors even on that machine, if I don't use DMA.
> Really weird. What scares me is that if I don't identify the problem,
> a similar crash may happen again...
>
> Cheers!
>
> [ François-René ÐVB Rideau | Reflection&Cybernethics |
> http://fare.tunes.org ] [  TUNES project for a Free Reflective Computing
> System  | http://tunes.org  ] Demand the establishment of the government in
> its rightful home at Disneyland.

-- 

Thanks,
Vitaly Fertman