Corruption: --fix-fixable results in all nlink values = 0

Corruption: --fix-fixable results in all nlink values = 0

[Gerrit Hannaert]

Hello,

I recently noticed some errors in my system log, and had already found a directory with a few files in it which could not be deleted. 
So I downloaded the newest reiserfs tools, compiled them and had a shot at reiserfsck --fix-fixable.
Big mistake. My 60GB filesystem had gone from slightly corrupt to becoming completely unmountable by doing this.

Some further analysis led me to the conclusion that *all* fields for nlink had become '0' (something I suppose shouldn't happen).

reiserfsprogs 3.6.3
filesystem version 3.6, created with something from 2.4.16 to .18
gcc used to compile: version 3.1.1 20020722 (prerelease) (SuSE Linux)
kernel 2.4.19 (compiled with same gcc)

What went wrong here? 
Will reiserfsck --rebuild-tree fix this? Or is the error some compilation thing? 
What are my chances to recover the filesystem?

Regards,

- Gerrit



--
luna:/ # mount /home
mount: Not a directory

-- /var/log/messages
Aug 15 19:40:51 luna kernel: reiserfs: found format "3.6" with standard journal
Aug 15 19:40:51 luna kernel: reiserfs: checking transaction log (ide0(3,9)) for (ide0(3,9))
Aug 15 19:40:51 luna kernel: reiserfs: using ordered data mode
Aug 15 19:40:51 luna kernel: vs-13075: reiserfs_read_inode2: dead inode read from disk [1 2 0x0 SD]. This is likely to be race with knfsd. Ign
ore
Aug 15 19:40:51 luna kernel: Using r5 hash to sort names

-- reiserfsck output
/  1 (of   4)/  1 (of 159)/  1 (of 169)bad_stat_data: block 8232, [1 2 0x0 SD (0)], directory SD has bad nlink number
bad_stat_data: block 8232, [2 3 0x0 SD (0)], directory SD has bad nlink number
bad_stat_data: block 8232, [2 13 0x0 SD (0)], directory SD has bad nlink number
bad_stat_data: block 8232, [2 14 0x0 SD (0)], directory SD has bad nlink number
/  2 (of 169)bad_stat_data: block 8233, [2 132 0x0 SD (0)], directory SD has bad nlink number
bad_stat_data: block 8233, [2 1855 0x0 SD (0)], directory SD has bad nlink number
/  5 (of 169)bad_stat_data: block 8755, [2 3793 0x0 SD (0)], directory SD has bad nlink number

-- ALL values of nlink are 0:
luna:/ # zcat /home.debugreiserfs.log.gz | grep "nlink"  | awk '{print $8}' | sort | uniq -c
 382201 0,

-- debugreiserfs output
Filesystem state: consistency is not checked after last mounting

Reiserfs super block in block 16 on 0x309 of format 3.6 with standard journal
Count of blocks on the device: 17638606
Number of bitmaps: 539
Blocksize: 4096
Free blocks (count of blocks - used [journal, bitmaps, data, reserved] blocks): 4826281
Root block: 39819
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 [0x38906a00]
        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
sb_version: 2
inode generation number: 12589619
UUID: 00000000-0000-0000-0000-000000000000
LABEL:
Set flags in SB:

INTERNAL NODE (39819) contains level=4, nr_items=3, free_space=3992 rdkey
PTR 0: [dc_number=8387, dc_size=3800] KEY 0: 68140 71445 0x1a07001 IND (1) PTR 1: [dc_number=713991, dc_size=2864] KEY 1: 1671434 1672343 0x4a
...
===================================================================
LEAF NODE (8232) contains level=1, nr_items=8, free_space=128 rdkey (real items 8)
-------------------------------------------------------------------------------
|###|type|ilen|f/sp| loc|fmt|fsck|                   key                      |
|   |    |    |e/cn|    |   |need|                                            |
-------------------------------------------------------------------------------
|  0|1 2 0x0 SD (0), len 44, location 4052 entry count 0, fsck need 0, format new|
(NEW SD), mode drwxr-xr-x, size 1408, nlink 0, mtime 07/19/2002 03:02:40 blocks 3, uid 0
-------------------------------------------------------------------------------
|  1|1 2 0x1 DIR (3), len 1408, location 2644 entry count 51, fsck need 0, format old|
###: Name                     length    Object key           Hash     Gen number
  0: ".                        "(  1)                 1 2           0    1, loc 1400, state 4 not set
  1: "..                       "(  2)                 0 1           0    2, loc 1392, state 4 not set
...
 49: "lost+found               "( 10)             2 26247  2077744896    0, loc 832, state 4 "r5"
 50: "bigfiles.list            "( 13)           2 2241662  2088467072    0, loc 816, state 4 "r5"
-------------------------------------------------------------------------------
|  2|2 3 0x0 SD (0), len 44, location 2600 entry count 65535, fsck need 0, format new|
(NEW SD), mode drwxr-xr-x, size 264, nlink 0, mtime 06/25/2000 19:48:19 blocks 1, uid 0
-------------------------------------------------------------------------------
|  3|2 3 0x1 DIR (3), len 264, location 2336 entry count 11, fsck need 0, format old|
###: Name                     length    Object key           Hash     Gen number
  0: ".                        "(  1)                 2 3           0    1, loc 256, state 4 not set
  1: "..                       "(  2)                 1 2           0    2, loc 248, state 4 not set
  2: "at                       "(  2)                 3 5      208896    0, loc 240, state 4 "r5"
  3: "kbd                      "(  3)                 3 8     2494720    0, loc 232, state 4 "r5"
  4: "bash                     "(  4)                 3 6    25360384    0, loc 224, state 4 "r5"
...

Re: Corruption: --fix-fixable results in all nlink values = 0

[Vitaly Fertman]

Hi,

On Thursday 15 August 2002 22:07, Gerrit Hannaert wrote:
> Hello,
>
> I recently noticed some errors in my system log, and had already found a
> directory with a few files in it which could not be deleted. So I
> downloaded the newest reiserfs tools, compiled them and had a shot at
> reiserfsck --fix-fixable. Big mistake. My 60GB filesystem had gone from

why did you decided to run fix-fixable? You run --check just before it
and it said to run --fix-fixable or what?

> slightly corrupt to becoming completely unmountable by doing this.
>
> Some further analysis led me to the conclusion that *all* fields for nlink
> had become '0' (something I suppose shouldn't happen).

Did reiserfsck finish its work or (was)stopped/failed?

> reiserfsprogs 3.6.3
> filesystem version 3.6, created with something from 2.4.16 to .18
> gcc used to compile: version 3.1.1 20020722 (prerelease) (SuSE Linux)
> kernel 2.4.19 (compiled with same gcc)
>
> What went wrong here?
> Will reiserfsck --rebuild-tree fix this? Or is the error some compilation
> thing? What are my chances to recover the filesystem?

Chances are good. No data ware lost and I am checking how reiserfsck handle 
direcory nlinks now. 

-- 

Thanks,
Vitaly Fertman

Re: Corruption: --fix-fixable results in all nlink values = 0

[Gerrit Hannaert]

>
> why did you decided to run fix-fixable? You run --check just before it
> and it said to run --fix-fixable or what?

Er... I confess it was just a hunch, I did run --check but as I recall it did 
not tell me to, it did say there were corruptions in any case. The filesystem 
needed fixing and fix-fixable seemed less drastic than rebuild... (The 
undeletable files were basically a thorn in my eye and I just wanted to be 
sure there were no corruptions other than these clearly visible ones).

>
> Did reiserfsck finish its work or (was)stopped/failed?

Yes, reiserfsck finished properly.

> > What went wrong here?
> > Will reiserfsck --rebuild-tree fix this? Or is the error some compilation
> > thing? What are my chances to recover the filesystem?
>
> Chances are good. No data ware lost and I am checking how reiserfsck handle
> direcory nlinks now.

It would be nice to recover most of the fs. I'd probably be better using some 
standard, tested reiserfsck-binaries over my own this time I suppose?

Thanks a lot, Vitaly.

- Gerrit

Re: Corruption: --fix-fixable results in all nlink values = 0

[Vitaly Fertman]

Hi, 

On Thursday 15 August 2002 22:36, Gerrit Hannaert wrote:
> > why did you decided to run fix-fixable? You run --check just before it
> > and it said to run --fix-fixable or what?
>
> Er... I confess it was just a hunch, I did run --check but as I recall it
> did not tell me to, it did say there were corruptions in any case. The
> filesystem needed fixing and fix-fixable seemed less drastic than
> rebuild... (The undeletable files were basically a thorn in my eye and I
> just wanted to be sure there were no corruptions other than these clearly
> visible ones).

Last reiserfscks say either 
There were found %d corruptions which can be fixed only during --rebuild-tree
or 
There were found %d corruptions which can be fixed with --fix-fixable
or 
No corruptions found.	

Do you remember what was there?

> > Did reiserfsck finish its work or (was)stopped/failed?
>
> Yes, reiserfsck finished properly.
>
> > > What went wrong here?
> > > Will reiserfsck --rebuild-tree fix this? Or is the error some
> > > compilation thing? What are my chances to recover the filesystem?
> >
> > Chances are good. No data ware lost and I am checking how reiserfsck
> > handle direcory nlinks now.
>
> It would be nice to recover most of the fs. I'd probably be better using
> some standard, tested reiserfsck-binaries over my own this time I suppose?

No problem in reiserfsck 3.6.3 found for now. I have just run --fix-fixable 
on a test partition, evth is fine. 

Ah, I guess I know what happened. I think you have some fatal corruptions and 
rebuild-tree is required. In this case check and fix-fixable do not perform 
semantic check.

To be able to solve the problem with nlinks without rebuild-tree, fix-fixable 
zeros them on the first check and increment nlinks during the semantic pass.

To check this guess - when you run check do you have the phrase:
Fatal corruptions were found, Semantic pass skipped?


-- 

Thanks,
Vitaly Fertman

Re: Corruption: --fix-fixable results in all nlink values = 0

[Gerrit Hannaert]

stderr reports near the end:

Comparing bitmaps..ok
Fatal corruptions were found, Semantic pass skipped
There were found 4 corruptions which can be fixed only during --rebuild-tree

So I guess I don't need to answer which output reiserfsck gave the first time 
;-)

(btw, It didn't say fix-fixable, and it didn't say no corruptions... hence...)

Many thanks for your help with my bungling...

- Gerrit


> > > why did you decided to run fix-fixable? You run --check just before it
> > > and it said to run --fix-fixable or what?
> >

> No problem in reiserfsck 3.6.3 found for now. I have just run --fix-fixable
> on a test partition, evth is fine.
>
> Ah, I guess I know what happened. I think you have some fatal corruptions
> and rebuild-tree is required. In this case check and fix-fixable do not
> perform semantic check.
>
> To be able to solve the problem with nlinks without rebuild-tree,
> fix-fixable zeros them on the first check and increment nlinks during the
> semantic pass.
>
> To check this guess - when you run check do you have the phrase:
> Fatal corruptions were found, Semantic pass skipped?

Re: Corruption: --fix-fixable results in all nlink values = 0

[Stefan Fleiter]

Hi Vitaly!

On Thu, 15 Aug 2002 Vitaly Fertman wrote:

> Ah, I guess I know what happened. I think you have some fatal corruptions and 
> rebuild-tree is required. In this case check and fix-fixable do not perform 
> semantic check.

Then reiserfsck should not start in fix-fixable mode when rebuild-tree is
required.
People think that fix-fiable is less dangerous. You have shown in some
situations it is the other way round...

I propos a new reiserfsck version with only this fix included!

Greets,
Stefan

Re: Corruption: --fix-fixable results in all nlink values = 0

[Gerrit Hannaert]

On Thursday 15 August 2002 21:44, Stefan Fleiter wrote:
> Hi Vitaly!
>
> On Thu, 15 Aug 2002 Vitaly Fertman wrote:
> > Ah, I guess I know what happened. I think you have some fatal corruptions
> > and rebuild-tree is required. In this case check and fix-fixable do not
> > perform semantic check.
>
> Then reiserfsck should not start in fix-fixable mode when rebuild-tree is
> required.
> People think that fix-fiable is less dangerous. You have shown in some
> situations it is the other way round...
>
> I propos a new reiserfsck version with only this fix included!
>
> Greets,
> Stefan


I admit the warning in the man page wasn't scary enough to me and led me to 
believe it was less dangerous, and thus worth a try first. It also seems
better to me to not allow fix-fixable to run in situations where it will not run 
properly (ie where a rebuild-tree is required)

Ciao,
- Gerrit

"--fix-fixable
This option recovers certain kinds of corruption that do not require  rebuilding  the  entire  file  system  tree
(--rebuild-tree).  Normally you only need this option if the --check option reports "corruption that can be fixed
with --fix-fixable". This includes: zeroing invalid data-block pointers, correcting  st_size  and  st_blocks  for
directories, and deleting invalid directory entries."

Re: Corruption: --fix-fixable results in all nlink values = 0

[Gerrit Hannaert]

Hi again,

Well, I decided to give rebuild-tree a try now, since the trouble was not with 
my binaries and I didn't know what else to do (maybe I should have waited). 
Unfortunately, it went bad after 60% or so.

What is there left to do? Will rebuilding again help this time around?

- Gerrit


reiserfsck --rebuild-tree /dev/hda9 

<-------------reiserfsck, 2002------------->
reiserfsprogs 3.6.3
...
Replaying journal..
0 transactions replayed
###########
reiserfsck --rebuild-tree started at Thu Aug 15 23:00:03 2002
###########

Pass 0:
Loading on-disk bitmap .. ok, 12812325 blocks marked used
Skipping 8749 blocks (super block, journal, bitmaps) 12803576 blocks will be 
read
0%....20%....40%....60%..                               left 3639489, 9322 
/sec
bread: Cannot read a block # 10146373.



####### Pass 0 #######
pass0: block 740209, item 3051935 2479726 0x1 DIR (3), len 168, location 2660 
entry count 7, fsck need 0, format old: 5 entries were deleted of
pass0: vpf-10480: block 983630, item (61), wrong order of items object_id of 
4460761 4460887 0x1 DRCT (2) fixed to 4462153
pass0: vpf-10500: block 983630, item (61), wrong order of items dir_id of 
4460761 4462153 0x1 DRCT (2) fixed to 4459536
pass0: vpf-10440: block 993396, item (44), wrong order of items dir_id of 
4597406 4601527 0x0 SD (0) fixed to 4601502

--

luna:/usr/src/reiserfsprogs-3.6.3 # reiserfsck /dev/hda9

<-------------reiserfsck, 2002------------->
reiserfsprogs 3.6.3

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

Do you want to run this program?[N/Yes] (note need to type Yes):Yes
###########
reiserfsck --check started at Thu Aug 15 23:24:57 2002
###########
Replaying journal..
0 transactions replayed
Checking S+tree..

Bad root block 4294967295. (--rebuild-tree did not complete)



Aborted

Re: Corruption: --fix-fixable results in all nlink values = 0

[Vitaly Fertman]

Hi, 

On Friday 16 August 2002 01:29, Gerrit Hannaert wrote:
> Hi again,
>
> Well, I decided to give rebuild-tree a try now, since the trouble was not
> with my binaries and I didn't know what else to do (maybe I should have
> waited). Unfortunately, it went bad after 60% or so.
>
> What is there left to do? Will rebuilding again help this time around?
>
> - Gerrit
>
>
> reiserfsck --rebuild-tree /dev/hda9
>
> <-------------reiserfsck, 2002------------->
> reiserfsprogs 3.6.3
> ...
> Replaying journal..
> 0 transactions replayed
> ###########
> reiserfsck --rebuild-tree started at Thu Aug 15 23:00:03 2002
> ###########
>
> Pass 0:
> Loading on-disk bitmap .. ok, 12812325 blocks marked used
> Skipping 8749 blocks (super block, journal, bitmaps) 12803576 blocks will
> be read
> 0%....20%....40%....60%..                               left 3639489, 9322
> /sec
> bread: Cannot read a block # 10146373.

It seems your hadrddrive has badblocks. At least 10146373 block (4k size) 
cannot be read. Have a look into your syslog for any related information.
If you have a faulty hardware and you need our assistance in recovering 
from it, please visit our support page first. 

-- 

Thanks,
Vitaly Fertman

Re: Corruption: --fix-fixable results in all nlink values = 0

[Gerrit Hannaert]

Hi Vitaly,

Your analysis is dead-on!

I ran reiserfsck a second time, and this time it stopped later.
The strange thing is this disk and installation are relatively new 
(March 2002), and digging back through syslogs shows occurances 
(kernel)(.*)(hda) only on:
4 May 20 (2 sectors)
370 Aug 15 (>100 different sectors involved)
34 Aug 16 (17 sectors)

...which means the problems only really started by all this fsck stuff. 
At least sectors 81170944 - 81171056 seem to be involved during 
yesterday and today. Why would these problems be so recent? The 
filesystem has been up to 95% full at times, and a lot of it is indexed 
with a web indexer daily, one would have expected this earlier, no?

I'll keep you posted if things fare worse (or better, hopefully),

- Gerrit


# first reiserfsck --rebuild-tree:

# bread: Cannot read a block # 10146373.

> Aug 15 23:16:31 luna kernel: hda: dma_intr: status=0x51 { DriveReady 
> SeekComplete Error }
> Aug 15 23:16:31 luna kernel: hda: dma_intr: error=0x40 { 
> UncorrectableError }, LBAsect=9641711
> 9, sector=81170984
> Aug 15 23:16:31 luna kernel: end_request: I/O error, dev 03:09 (hda), 
> sector 81170984

# second time:

# bread: Cannot read a block # 10146381.

> Aug 16 03:01:40 luna kernel: hda: read_intr: status=0x59 { DriveReady 
> SeekComplete DataRequest
>  Error }
> Aug 16 03:01:40 luna kernel: hda: read_intr: error=0x40 { 
> UncorrectableError }, LBAsect=964171
> 11, sector=81171048
> Aug 16 03:01:40 luna kernel: end_request: I/O error, dev 03:09 (hda), 
> sector 81171048





Vitaly Fertman wrote:

>It seems your hadrddrive has badblocks. At least 10146373 block (4k size) 
>cannot be read. Have a look into your syslog for any related information.
>If you have a faulty hardware and you need our assistance in recovering 
>from it, please visit our support page first. 
>

Re: Corruption: --fix-fixable results in all nlink values = 0

[Matthias Andree]

Stefan Fleiter <stefan.fleiter@gmx.de> writes:

> Hi Vitaly!
>
> On Thu, 15 Aug 2002 Vitaly Fertman wrote:
>
>> Ah, I guess I know what happened. I think you have some fatal corruptions and 
>> rebuild-tree is required. In this case check and fix-fixable do not perform 
>> semantic check.
>
> Then reiserfsck should not start in fix-fixable mode when rebuild-tree is
> required.
> People think that fix-fiable is less dangerous. You have shown in some
> situations it is the other way round...
>
> I propos a new reiserfsck version with only this fix included!

Hum, if reiserfsck can tell if fix-fixable or rebuild-tree is the right
one, then it should also be able to abort the fix-fixable run and tell
the user to run rebuild-tree. Maybe such "needs-fix-fixable" and
"needs-rebuild-tree" flags should be stored into the super block, much
like ext2 stores the "file system with errors" condition.

-- 
Matthias Andree

Re: Corruption: --fix-fixable results in all nlink values = 0

[Matthias Andree]

Gerrit Hannaert <degerrit@web.de> writes:

> I ran reiserfsck a second time, and this time it stopped later.
> The strange thing is this disk and installation are relatively new
> (March 2002), and digging back through syslogs shows occurances
> (kernel)(.*)(hda) only on:
> 4 May 20 (2 sectors)
> 370 Aug 15 (>100 different sectors involved)
> 34 Aug 16 (17 sectors)
>
> ...which means the problems only really started by all this fsck
> stuff.

No way fsck caused these. The problems were there, you just did not see
them, because you did not read the defective blocks before. Unless the
drive has suffered inadequate treatment, (dropped, computer kicked or
bumped into, overheat) better return it for warranty repair or
replacement pretty soon; assuming it was bought in Germany, after 6
months after purchase, YOU may have to prove the drive was defective on
delivery, before that, the dealer will have to prove it was intact if he
is to refuse warranty repair.

>> Aug 15 23:16:31 luna kernel: hda: dma_intr: status=0x51 { DriveReady
>> SeekComplete Error }
>> Aug 15 23:16:31 luna kernel: hda: dma_intr: error=0x40 {
>> UncorrectableError }, LBAsect=9641711

Your drive is broken. Such things can happen for a block or two after
power failure in the mid of a write process and will then go away the
next time the block is written again. What drive type is this? (to find
that out, use: cat /proc/ide/hda/model)

-- 
Matthias Andree

Re: Corruption: --fix-fixable results in all nlink values = 0

[Gerrit Hannaert]

Hi Matthias,

>No way fsck caused these. The problems were there, you just did not see
>them, because you did not read the defective blocks before. Unless the
>drive has suffered inadequate treatment, (dropped, computer kicked or
>bumped into, overheat) better return it for warranty repair or
>replacement pretty soon; assuming it was bought in Germany, after 6
>months after purchase, YOU may have to prove the drive was defective on
>delivery, before that, the dealer will have to prove it was intact if he
>is to refuse warranty repair.
>
Is there a difference in the way reiserfs formats as opposed to ext2/3? 
Your mentioning the defective blocks were never read before reminds me 
of the fact that a Reiserfs format is much quicker than any other 
filesystem's format - does it mean anything? Perhaps it is good practice 
to run 'badblocks' before any initial format... if there is no option to 
format/scan or something.

>next time the block is written again. What drive type is this? (to find
>that out, use: cat /proc/ide/hda/model)
>  
>
This one is a MAXTOR 6L080J4. But I've seen these 'dma' issues with 
*all* my other drives as well (IBM-DTLA-307045, FUJITSU MPE3136AH) on 
different PCs with Intel and Via motherboards.
But honestly, I treat my drives very nicely... I swear :-)

- Gerrit

Re: Corruption: --fix-fixable results in all nlink values = 0

[Matthias Andree]

Gerrit Hannaert <degerrit@web.de> writes:

> Is there a difference in the way reiserfs formats as opposed to ext2/3?
> Your mentioning the defective blocks were never read before reminds me

Well, the long explanation is, that the blocks may not have been used
for some time, or that they have gone bad recently, such things happen,
although you'd expect that from DTLA-3070xx drives earlier than from
others.

> of the fact that a Reiserfs format is much quicker than any other
> filesystem's format - does it mean anything?

The on-disk layout is different, but I'm not aware of the internals, and
I don't believe that the allocation pattern changes anything about the
facts.

> Perhaps it is good practice to run 'badblocks' before any initial
> format... if there is no option to format/scan or something.

Neither mke2fs nor mkreiserfs read or write all blocks when formatting,
they instead write some meta data, and that's it. Of course, running
badblocks prior to formatting is an option to find these earlier.

> This one is a MAXTOR 6L080J4. But I've seen these 'dma' issues with
> *all* my other drives as well (IBM-DTLA-307045, FUJITSU MPE3136AH) on
> different PCs with Intel and Via motherboards.

It's not "dma" but the "unrecoverable error" part that matters. The DMA
trips over as consequence of this defective block (there is no data that
could be transferred), the DMA is *not* the cause for the bad block.

-- 
Matthias Andree

Re: Corruption: --fix-fixable results in all nlink values = 0

[Hans Reiser]

A colleague of mine back when I was part of a sysadmin department used 
to write to every block on the drive before installing the OS on it.  I 
think he was right to do so.  I have considered having mkreiserfs ask 
the user if he wants to do that.

-- 
Hans

Re: Corruption: --fix-fixable results in all nlink values = 0

[bscott]

On Fri, 16 Aug 2002, at 6:24pm, Hans Reiser wrote:
> A colleague of mine back when I was part of a sysadmin department used to
> write to every block on the drive before installing the OS on it.  I think
> he was right to do so.  I have considered having mkreiserfs ask the user
> if he wants to do that.

  I usually do a "badblocks -w" on any new disk before putting it into
production for that reason.

-- 
Ben Scott <bscott@ntisys.com>
| The opinions expressed in this message are those of the author and do not |
| necessarily represent the views or policy of any other person, entity or  |
| organization.  All information is provided without warranty of any kind.  |

Re: Corruption: --fix-fixable results in all nlink values = 0

[Matthias Andree]

On Fri, 16 Aug 2002, Hans Reiser wrote:

> A colleague of mine back when I was part of a sysadmin department used 
> to write to every block on the drive before installing the OS on it.  I 
> think he was right to do so.  I have considered having mkreiserfs ask 
> the user if he wants to do that.

badblocks has options to do so, so just running badblocks with the right
options should be sufficient. 

Re: Corruption: --fix-fixable results in all nlink values = 0

[Vitaly Fertman]

On Friday 16 August 2002 14:42, Matthias Andree wrote:
> Stefan Fleiter <stefan.fleiter@gmx.de> writes:
> > Hi Vitaly!
> >
> > On Thu, 15 Aug 2002 Vitaly Fertman wrote:
> >> Ah, I guess I know what happened. I think you have some fatal
> >> corruptions and rebuild-tree is required. In this case check and
> >> fix-fixable do not perform semantic check.
> >
> > Then reiserfsck should not start in fix-fixable mode when rebuild-tree is
> > required.
> > People think that fix-fiable is less dangerous. You have shown in some
> > situations it is the other way round...
> >
> > I propos a new reiserfsck version with only this fix included!
>
> Hum, if reiserfsck can tell if fix-fixable or rebuild-tree is the right
> one, then it should also be able to abort the fix-fixable run and tell
> the user to run rebuild-tree. Maybe such "needs-fix-fixable" and
> "needs-rebuild-tree" flags should be stored into the super block, much
> like ext2 stores the "file system with errors" condition.

The problem is that between check and fix-fixable/rebuild-tree a user can 
do some actions which can lead to changing the state of the fs. One wants 
to mount it as he cannot afford to run rebuild-tree at the time, this may  
lead to fatal corruptions on the fs. Even if we won't allow a such fs to be 
mountable, old kernels will continue doing it, so SB flags do not help a lot. 

The last decision after some discussion was to leave ulinks recovering in 
the rebuild-tree only.

-- 

Thanks,
Vitaly Fertman

search for mailing archive on geocrawler

[bo]

Hello,

Could anyone give me a quick hand "How to search a
special topic or issue from the mailing archive on www.geocrawler.com"?

Under the www.geocrawler.com, there are LINUX, RAID, REISERFS
mailing archives, and then several thousands of email archive under each
one.

I could step through each email, but I want to search my issue or topic
quickly.

Of course, I could search it from www.google.com.

Thanks,

Bo

Re: Corruption: --fix-fixable results in all nlink values = 0

[Gerrit Hannaert]

Hi again,

I skimmed over the bad-block-handling page but it's not very clear what you 
should do if a filesystem already exists, as is obviously the case with me. 
Are these badblock patches in the newer kernels, by the way?

Anyway, my first instinct told me to try Maxtor's 'Powermax' tool, and lo and 
behold the 'Advanced Test' here found errors, and 'fixed' them, whatever that 
means. (Can you believe these guys make you download a 3MB Windows executable 
in order to write a 1.44Mb floppy image which is less than half full?? I had 
to bloody install Windows for this... grr....)

Anyway, this time 'reiserfsck --rebuild-tree' finished successfully, and I was 
able to see my filesystem for the first time in 2 days and many hours of 
sweating. 
Here's the pretty impressive summary of errors:

Pass 0:
Loading on-disk bitmap .. ok, 12812325 blocks marked used
Skipping 8749 blocks (super block, journal, bitmaps) 12803576 blocks will be 
read
...
        "r5" hash is selected
Flushing..done
        Read blocks (but not data blocks) 12803576
                Leaves among those 86209
                        - corrected leaves 1
                Objectids found 382476

Pass 1 (will try to insert 86209 leaves):
Looking for allocable blocks .. ok
...
Flushing..done
        Leaves inserted item by item 170
Pass 3 (semantic):
####### Pass 0 #######
pass0: vpf-10420: block 983630, item (61), make 4459536 4462153 0x1 IND (1) 
fixed to DIRECT
"r5" got 382518 hits
####### Pass 1 #######
is_leaf_bad: block 983630L 60-th item (4459536 4462153 0x1 IND (1), len 28, 
location 1792 entry count 0, fsck need 0, format new) and the next
 one (4459536 4462153 0x7001 IND (1), len 280, location 1512 entry count 
65535, fsck need 0, format new) are in wrong order
pass1: (is_leaf_bad) bad leaf (983630)
####### Pass 2 #######
...
Flushing..done
        Objects without names 185
        Empty lost dirs removed 602
        Dirs linked to /lost+found: 12
                Dirs without stat data found 60
        Files linked to /lost+found 161
        Objects having used objectids: 10
                files fixed 66
                dirs fixed 3
Pass 4
Deleted unreachable items 5
Flushing..done
Syncing..done
###########
reiserfsck finished at Sat Aug 17 02:20:46 2002

I think I will spend the next week working out a better backup solution...

Will Reiserfs4 have better bad block handling than this? When I see all the 
trouble involved in rescuing this filesystem, as much as I'm impressed with 
it I would think twice about using Reiserfs on any non-redundant (and 
certainly IDE) disks from now on. I hope I don't make any enemies by saying 
so.

Cheers, and thanks for all your help, especially Vitaly!

- Gerrit

Re: search for mailing archive on geocrawler

[Manuel Krause]

On 08/17/2002 02:18 AM, bo wrote:
> Hello,
> 
> Could anyone give me a quick hand "How to search a
> special topic or issue from the mailing archive on www.geocrawler.com"?
> 
> Under the www.geocrawler.com, there are LINUX, RAID, REISERFS
> mailing archives, and then several thousands of email archive under each
> one.

You mean
  http://www.geocrawler.com/lists/3/Linux/3455/0/
?

:-(

> 
> I could step through each email, but I want to search my issue or topic
> quickly.

You're obviously right -- no usable search possible :-(
IIRC, I was unlucky to use this archive when I followed the linux-usb 
stuff some months ago. Quite unusable.

The look and usability reminds me of the sourceforge.net project 
listings and related mail archives some months ago. Some sites even are 
not able to sort their topics alphabetically though having some hundreds 
in one page...

> 
> Of course, I could search it from www.google.com.
> 



Maybe you want to try
  http://marc.theaimsgroup.com/?l=reiserfs&r=1&w=4
instead and go to the date section directly or test the search function 
on the top of the page. I just did it with the topic "data-logging" and 
it worked. I didn't go in depth (if it even searches mail bodies) for now.

I have another ReiserFS mailing list archive in my bookmarks:
  http://lists.omnipotent.net/reiserfs/
but it is not up at the moment (read http://lists.omnipotent.net/ ) so I 
can't say if the search function [exists,works].


Best wishes,

Manuel

Re: Corruption: --fix-fixable results in all nlink values = 0

[Matthias Andree]

Gerrit Hannaert <degerrit@web.de> writes:

> Anyway, my first instinct told me to try Maxtor's 'Powermax' tool, and
> lo and behold the 'Advanced Test' here found errors, and 'fixed' them,
> whatever that means. (Can you believe these guys make you download a
> 3MB Windows executable in order to write a 1.44Mb floppy image which
> is less than half full?? I had to bloody install Windows for
> this... grr....)

So complain and ask them to make a gzipped floppy image for Linux and
*BSD users, and offer to send them one :-)

> I think I will spend the next week working out a better backup
> solution...

...and finding out if files have been damaged.

> Will Reiserfs4 have better bad block handling than this? When I see all the 
> trouble involved in rescuing this filesystem, as much as I'm impressed with 
> it I would think twice about using Reiserfs on any non-redundant (and 
> certainly IDE) disks from now on. I hope I don't make any enemies by saying 
> so.

Any file system can screw up if the hardware fails in the wrong
place. If what I'd call "file header" blocks are struck, the file name
(at least) is gone, on some file systems the whole file. So there.

Are there file systems that checksum the files' and directory data, to
be able to flag files as broken if a bad block strikes?

-- 
Matthias Andree

Re: Corruption: --fix-fixable results in all nlink values = 0

[Hans Reiser]

Matthias Andree wrote:

>Gerrit Hannaert <degerrit@web.de> writes:
>
>  
>
>>Anyway, my first instinct told me to try Maxtor's 'Powermax' tool, and
>>lo and behold the 'Advanced Test' here found errors, and 'fixed' them,
>>whatever that means. (Can you believe these guys make you download a
>>3MB Windows executable in order to write a 1.44Mb floppy image which
>>is less than half full?? I had to bloody install Windows for
>>this... grr....)
>>    
>>
>
>So complain and ask them to make a gzipped floppy image for Linux and
>*BSD users, and offer to send them one :-)
>
>  
>
>>I think I will spend the next week working out a better backup
>>solution...
>>    
>>
>
>...and finding out if files have been damaged.
>
>  
>
>>Will Reiserfs4 have better bad block handling than this? When I see all the 
>>trouble involved in rescuing this filesystem, as much as I'm impressed with 
>>it I would think twice about using Reiserfs on any non-redundant (and 
>>certainly IDE) disks from now on. I hope I don't make any enemies by saying 
>>so.
>>    
>>
>
>Any file system can screw up if the hardware fails in the wrong
>place. If what I'd call "file header" blocks are struck, the file name
>(at least) is gone, on some file systems the whole file. So there.
>
>Are there file systems that checksum the files' and directory data, to
>be able to flag files as broken if a bad block strikes?
>
>  
>
Nikita wrote a badblocks patch.

The main reason for resisting doing it is that it is usually better to 
just write to the bad block, and let the hard drive remap the block.

Oleg, maybe send it into 2.5?

Hans

Re: Corruption: --fix-fixable results in all nlink values = 0

[Brian Tinsley]

Although it could take quite some time to do this with large RAID 
devices like we use, I believe this option definitely has some value. I 
would make this part of our standard build process if it were available.


Hans Reiser wrote:

> A colleague of mine back when I was part of a sysadmin department used 
> to write to every block on the drive before installing the OS on it.  
> I think he was right to do so.  I have considered having mkreiserfs 
> ask the user if he wants to do that.
>

-- 
Brian Tinsley
Chief Systems Engineer
Emageon
http://www.emageon.com/

Re: Corruption: --fix-fixable results in all nlink values = 0

[Oleg Drokin]

Hello!

On Sat, Aug 17, 2002 at 11:00:57PM +0400, Hans Reiser wrote:

> Nikita wrote a badblocks patch.
> The main reason for resisting doing it is that it is usually better to 
> just write to the bad block, and let the hard drive remap the block.
> 
> Oleg, maybe send it into 2.5?

I think I have somewhat better patch and reiserfsck is also prepared for that
(disabled at compile time, though).
The only thing is we had not agreed on unused key to put list of badblocks into
and Chris does not agree that we have store such an info on FS.

I will prepare a patch for 2.5.

Bye,
    Oleg

Re: Corruption: --fix-fixable results in all nlink values = 0

[Hans Reiser]

Brian Tinsley wrote:

> Although it could take quite some time to do this with large RAID 
> devices like we use, I believe this option definitely has some value. 
> I would make this part of our standard build process if it were 
> available.
>
>
> Hans Reiser wrote:
>
>> A colleague of mine back when I was part of a sysadmin department 
>> used to write to every block on the drive before installing the OS on 
>> it. I think he was right to do so. I have considered having 
>> mkreiserfs ask the user if he wants to do that.
>>
>
(You can use dd for now, or badblocks.)

Ok, Vitaly, look into adding this to mkreiser4. It is not that users 
cannot do it themselves, it is that they deserve a prompting reminder.

Tell users:

"Would you like us to write to every block on the partition before 
installing the filesystem on it? This will take a very long time, and is 
appropriate for persons willing to wait a day before proceeding. It is 
useful because it will cause the disk drive to remap bad sectors it 
finds, and cautious sysadmins not in a particular hurry sometimes like 
to do this."

Then take a look at the badblocks program, and decide whether we should 
use that or dd for this purpose, and whether we should read as well as 
write.

Hans

Re: Corruption: --fix-fixable results in all nlink values = 0

[Hans Reiser]

Oleg Drokin wrote:

>Hello!
>
>On Sat, Aug 17, 2002 at 11:00:57PM +0400, Hans Reiser wrote:
>
>  
>
>>Nikita wrote a badblocks patch.
>>The main reason for resisting doing it is that it is usually better to 
>>just write to the bad block, and let the hard drive remap the block.
>>
>>Oleg, maybe send it into 2.5?
>>    
>>
>
>I think I have somewhat better patch and reiserfsck is also prepared for that
>(disabled at compile time, though).
>The only thing is we had not agreed on unused key to put list of badblocks into
>and Chris does not agree that we have store such an info on FS.
>
What is his argument?

>
>I will prepare a patch for 2.5.
>
>Bye,
>    Oleg
>
>
>  
>

Re: Corruption: --fix-fixable results in all nlink values = 0

[Oleg Drokin]

Hello!

On Mon, Aug 19, 2002 at 12:42:11PM +0400, Hans Reiser wrote:

> >The only thing is we had not agreed on unused key to put list of badblocks 
> >into
> >and Chris does not agree that we have store such an info on FS.
> What is his argument?

He argues that if we'd had corrupted tree, how would we know that the bablocks
list is corrupted or not. Or something like that.

Bye,
    Oleg

Re: Corruption: --fix-fixable results in all nlink values = 0

[Hans Reiser]

Oleg Drokin wrote:

>Hello!
>
>On Mon, Aug 19, 2002 at 12:42:11PM +0400, Hans Reiser wrote:
>
>  
>
>>>The only thing is we had not agreed on unused key to put list of badblocks 
>>>into
>>>and Chris does not agree that we have store such an info on FS.
>>>      
>>>
>>What is his argument?
>>    
>>
>
>He argues that if we'd had corrupted tree, how would we know that the bablocks
>list is corrupted or not. Or something like that.
>
>Bye,
>    Oleg
>
>
>  
>
And he suggests doing what instead?

Re: Corruption: --fix-fixable results in all nlink values = 0

[Oleg Drokin]

Hello!

On Mon, Aug 19, 2002 at 01:14:10PM +0400, Hans Reiser wrote:
> >He argues that if we'd had corrupted tree, how would we know that the 
> >bablocks
> >list is corrupted or not. Or something like that.
> And he suggests doing what instead?

He suggests that user should specify list of bad blocks each time user runs
reiserfsck.

Bye,
    Oleg

Re: Corruption: --fix-fixable results in all nlink values = 0

[Hans Reiser]

Oleg Drokin wrote:

>Hello!
>
>On Mon, Aug 19, 2002 at 01:14:10PM +0400, Hans Reiser wrote:
>  
>
>>>He argues that if we'd had corrupted tree, how would we know that the 
>>>bablocks
>>>list is corrupted or not. Or something like that.
>>>      
>>>
>>And he suggests doing what instead?
>>    
>>
>
>He suggests that user should specify list of bad blocks each time user runs
>reiserfsck.
>
>Bye,
>    Oleg
>
>
>  
>
This sounds reasonable.  You can probably even have a default location 
to check for the list somewhere in /etc if you want.  Remind the user 
that you are using it everytime you find it though, that way if a 
different sysadmin is running fsck, they can know why not all the blocks 
they expect to be there are accessible.

Hans

Re: Corruption: --fix-fixable results in all nlink values = 0

[Oleg Drokin]

Hello!

On Mon, Aug 19, 2002 at 02:07:26PM +0400, Hans Reiser wrote:

> >He suggests that user should specify list of bad blocks each time user runs
> >reiserfsck.
> This sounds reasonable.  You can probably even have a default location 

Not for me.

> to check for the list somewhere in /etc if you want.  Remind the user 

File can get corrupted too.

> that you are using it everytime you find it though, that way if a 
> different sysadmin is running fsck, they can know why not all the blocks 
> they expect to be there are accessible.

Having some config files for this purpose is not good.
What if I have booted from rescue disk?

Bye,
    Oleg

Re: Corruption: --fix-fixable results in all nlink values = 0

[Hans Reiser]

Oleg Drokin wrote:

>Hello!
>
>On Mon, Aug 19, 2002 at 02:07:26PM +0400, Hans Reiser wrote:
>
>  
>
>>>He suggests that user should specify list of bad blocks each time user runs
>>>reiserfsck.
>>>      
>>>
>>This sounds reasonable.  You can probably even have a default location 
>>    
>>
>
>Not for me.
>
>  
>
>>to check for the list somewhere in /etc if you want.  Remind the user 
>>    
>>
>
>File can get corrupted too.
>
>
>  
>
>>that you are using it everytime you find it though, that way if a 
>>different sysadmin is running fsck, they can know why not all the blocks 
>>they expect to be there are accessible.
>>    
>>
>
>Having some config files for this purpose is not good.
>What if I have booted from rescue disk?
>
>Bye,
>    Oleg
>
>
>  
>
That is why it is only the DEFAULT location, and (slight improvement 
here) the user is prompted about whether to use it.

Re: Corruption: --fix-fixable results in all nlink values = 0

[Oleg Drokin]

Hello!

On Mon, Aug 19, 2002 at 02:27:59PM +0400, Hans Reiser wrote:

> >>that you are using it everytime you find it though, that way if a 
> >>different sysadmin is running fsck, they can know why not all the blocks 
> >>they expect to be there are accessible.
> >Having some config files for this purpose is not good.
> >What if I have booted from rescue disk?
> That is why it is only the DEFAULT location, and (slight improvement 
> here) the user is prompted about whether to use it.

This is still too error prone, I think it is better to have this info on FS.
(this does not destroy ability of externally specifying other source of list of
bad blocks of course).
And we may ask user whenever to use this info from FS if detected, too.

Bye,
    Oleg

Re: Corruption: --fix-fixable results in all nlink values = 0

[Hans Reiser]

Oleg Drokin wrote:

>Hello!
>
>On Mon, Aug 19, 2002 at 02:27:59PM +0400, Hans Reiser wrote:
>
>  
>
>>>>that you are using it everytime you find it though, that way if a 
>>>>different sysadmin is running fsck, they can know why not all the blocks 
>>>>they expect to be there are accessible.
>>>>        
>>>>
>>>Having some config files for this purpose is not good.
>>>What if I have booted from rescue disk?
>>>      
>>>
>>That is why it is only the DEFAULT location, and (slight improvement 
>>here) the user is prompted about whether to use it.
>>    
>>
>
>This is still too error prone, I think it is better to have this info on FS.
>
How does that make it less error prone?  It sounds like more complex 
code to me, especially considering that in the worst case the user 
reruns badblocks to generate the data again.

>(this does not destroy ability of externally specifying other source of list of
>bad blocks of course).
>And we may ask user whenever to use this info from FS if detected, too.
>
>Bye,
>    Oleg
>
>
>  
>

Re: Corruption: --fix-fixable results in all nlink values = 0

[Oleg Drokin]

Hello!

On Mon, Aug 19, 2002 at 03:14:12PM +0400, Hans Reiser wrote:
> >>>>that you are using it everytime you find it though, that way if a 
> >>>>different sysadmin is running fsck, they can know why not all the blocks 
> >>>>they expect to be there are accessible.
> >>>Having some config files for this purpose is not good.
> >>>What if I have booted from rescue disk?
> >>That is why it is only the DEFAULT location, and (slight improvement 
> >>here) the user is prompted about whether to use it.
> >This is still too error prone, I think it is better to have this info on 
> >FS.
> How does that make it less error prone?  It sounds like more complex 
> code to me, especially considering that in the worst case the user 
> reruns badblocks to generate the data again.

Less error prone in the sence that the data is contained within FS itself, so
the only way to get it wrong is FS corruption due to HW problems/kernel bug.

If we only rely on expernal source, user might forget to specify this file
(or simply he can be unaware that there is such a file) and all bad blocks
would be marked as free to use, wrong list of bad blocks might be specified
and so on.

Bye,
    Oleg

Re: Corruption: --fix-fixable results in all nlink values = 0

[Hans Reiser]

Oleg Drokin wrote:

>Hello!
>
>On Mon, Aug 19, 2002 at 03:14:12PM +0400, Hans Reiser wrote:
>  
>
>>>>>>that you are using it everytime you find it though, that way if a 
>>>>>>different sysadmin is running fsck, they can know why not all the blocks 
>>>>>>they expect to be there are accessible.
>>>>>>            
>>>>>>
>>>>>Having some config files for this purpose is not good.
>>>>>What if I have booted from rescue disk?
>>>>>          
>>>>>
>>>>That is why it is only the DEFAULT location, and (slight improvement 
>>>>here) the user is prompted about whether to use it.
>>>>        
>>>>
>>>This is still too error prone, I think it is better to have this info on 
>>>FS.
>>>      
>>>
>>How does that make it less error prone?  It sounds like more complex 
>>code to me, especially considering that in the worst case the user 
>>reruns badblocks to generate the data again.
>>    
>>
>
>Less error prone in the sence that the data is contained within FS itself, so
>the only way to get it wrong is FS corruption due to HW problems/kernel bug.
>
>If we only rely on expernal source, user might forget to specify this file
>(or simply he can be unaware that there is such a file) and all bad blocks
>would be marked as free to use, wrong list of bad blocks might be specified
>and so on.
>
>Bye,
>    Oleg
>
>
>  
>
I want it to use /etc/badblocks file if it exists, and if it uses then 
tell the user it is using it.  The user may also specify a file to use 
on the commandline.  Whether the user uses a file he specifies instead 
of /etc/badblocks is up to the user.

Re: Corruption: --fix-fixable results in all nlink values = 0

[Oleg Drokin]

Hello!

On Mon, Aug 19, 2002 at 05:29:48PM +0400, Hans Reiser wrote:

> I want it to use /etc/badblocks file if it exists, and if it uses then 

/etc/badblocks for which volume, how about other mounted volumes?
(appending volume name won't work, as these may easily move by itself, esp. on
scsi)

> tell the user it is using it.  The user may also specify a file to use 
> on the commandline.  Whether the user uses a file he specifies instead 
> of /etc/badblocks is up to the user.

Bye,
    Oleg

Re: Corruption: --fix-fixable results in all nlink values = 0

[Matthias Andree]

On Mon, 19 Aug 2002, Oleg Drokin wrote:

> Hello!
> 
> On Mon, Aug 19, 2002 at 05:29:48PM +0400, Hans Reiser wrote:
> 
> > I want it to use /etc/badblocks file if it exists, and if it uses then 
> 
> /etc/badblocks for which volume, how about other mounted volumes?
> (appending volume name won't work, as these may easily move by itself, esp. on
> scsi)

And a UUID (not sure if reiserfs has one, ext2fs/ext3fs have) can again
fall prey to corruption, but would otherwise be invariant to moving the
partition around (be it pvmove, adding another SCSI drive, you name it).

Re: Corruption: --fix-fixable results in all nlink values = 0

[Hans Reiser]

Oleg Drokin wrote:

>Hello!
>
>On Mon, Aug 19, 2002 at 05:29:48PM +0400, Hans Reiser wrote:
>
>  
>
>>I want it to use /etc/badblocks file if it exists, and if it uses then 
>>    
>>
>
>/etc/badblocks for which volume, how about other mounted volumes?
>(appending volume name won't work, as these may easily move by itself, esp. on
>scsi)
>
>  
>
>>tell the user it is using it.  The user may also specify a file to use 
>>on the commandline.  Whether the user uses a file he specifies instead 
>>of /etc/badblocks is up to the user.
>>    
>>
>
>Bye,
>    Oleg
>
>
>  
>
ok, then chris is right.  The user must specify it with every fsck.  You 
could use the UUID as part of the name, but that would be more work to code.

Hans

Re: Corruption: --fix-fixable results in all nlink values = 0

[Chris Mason]

On Mon, 2002-08-19 at 06:20, Oleg Drokin wrote:
> Hello!
> 
> On Mon, Aug 19, 2002 at 02:07:26PM +0400, Hans Reiser wrote:
> 
> > >He suggests that user should specify list of bad blocks each time user runs
> > >reiserfsck.
> > This sounds reasonable.  You can probably even have a default location 
> 
> Not for me.
> 
> > to check for the list somewhere in /etc if you want.  Remind the user 
> 
> File can get corrupted too.

You'd have to include some kind of checksum of the bad blocks lists to
make sure it was valid, regardless of where you stored it.  The problem
is that if you store it in the tree somehow, you've got a chicken and
egg problem that you can't read the list until the tree is good and you
can read the tree without knowing which blocks are bad.

It needs to be stored outside the btree, in its own data structure.

This could be a file on a different filesystem, or on a floppy, or in
something special you put into the FS.

-chris

Re: Corruption: --fix-fixable results in all nlink values = 0

[Oleg Drokin]

Hello!

On Tue, Aug 20, 2002 at 04:24:13PM -0400, Chris Mason wrote:

> make sure it was valid, regardless of where you stored it.  The problem
> is that if you store it in the tree somehow, you've got a chicken and
> egg problem that you can't read the list until the tree is good and you
> can read the tree without knowing which blocks are bad.

With carefully choosen key, it will be in fixed tree position.
But well, if Hans decided it should not be stored in a tree - so be it.

Bye,
    Oleg

Re: Corruption: --fix-fixable results in all nlink values = 0

[Hans Reiser]

Oleg Drokin wrote:

>Hello!
>
>On Tue, Aug 20, 2002 at 04:24:13PM -0400, Chris Mason wrote:
>
>  
>
>>make sure it was valid, regardless of where you stored it.  The problem
>>is that if you store it in the tree somehow, you've got a chicken and
>>egg problem that you can't read the list until the tree is good and you
>>can read the tree without knowing which blocks are bad.
>>    
>>
>
>With carefully choosen key, it will be in fixed tree position.
>But well, if Hans decided it should not be stored in a tree - so be it.
>
>Bye,
>    Oleg
>
>
>  
>
It is not that I oppose putting it into the tree with a fixed key for 
the file holding it, it is that I want us to work on other things instead.

Hans

Re: Corruption: --fix-fixable results in all nlink values = 0

[Gerrit Hannaert]

Hans Reiser wrote:

> It is not that I oppose putting it into the tree with a fixed key for 
> the file holding it, it is that I want us to work on other things instead.
>
> Hans


Why not just run 'badblocks' (or the failure mechanism which now aborts 
with "bread: Cannot read a block") as an (optional) part of fsck and use 
the output in a bad-block-marking phase? Then you don't need to store 
the list of bad blocks anywhere, at least not for fsck anyway ;-). 
Personally though, as a user, I'd like to confirm the list of bad blocks 
in this case (in case it's too large I might decide not to do it...)

It wasn't even clear to me until last week that the hard disk *also* did 
remapping of bad blocks, whether automatically or with some vendor-tool. 
Perhaps any fsck failure due to hardware error should recommend using 
low-level disk-checking tools provided by hard disk vendors prior to 
taking any action itself?

- Gerrit

Re: Corruption: --fix-fixable results in all nlink values = 0

[Hans Reiser]

Gerrit Hannaert wrote:

> Hans Reiser wrote:
>
>> It is not that I oppose putting it into the tree with a fixed key for 
>> the file holding it, it is that I want us to work on other things 
>> instead.
>>
>> Hans
>
>
>
> Why not just run 'badblocks' (or the failure mechanism which now 
> aborts with "bread: Cannot read a block") as an (optional) part of 
> fsck and use the output in a bad-block-marking phase? 

This is good UI design.  Vitaly....

> Then you don't need to store the list of bad blocks anywhere, at least 
> not for fsck anyway ;-). Personally though, as a user, I'd like to 
> confirm the list of bad blocks in this case (in case it's too large I 
> might decide not to do it...)
>
> It wasn't even clear to me until last week that the hard disk *also* 
> did remapping of bad blocks, whether automatically or with some 
> vendor-tool. Perhaps any fsck failure due to hardware error should 
> recommend using low-level disk-checking tools provided by hard disk 
> vendors prior to taking any action itself?
>
> - Gerrit
>
>
>
>

Re: Corruption: --fix-fixable results in all nlink values = 0

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 590 bytes --]

On Wed, 21 Aug 2002 21:14:49 +0400, Hans Reiser said:

> > Why not just run 'badblocks' (or the failure mechanism which now 
> > aborts with "bread: Cannot read a block") as an (optional) part of 
> > fsck and use the output in a bad-block-marking phase? 
> 
> This is good UI design.  Vitaly....

Certainly make it optional (or optionally disabled) - having to read 300G of
data blocks when you know that the media is good would be massive overkill,
when you're rebooting after a panic for other reasons. ;)
-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Corruption: --fix-fixable results in all nlink values = 0

[Hans Reiser]

Valdis.Kletnieks@vt.edu wrote:

>On Wed, 21 Aug 2002 21:14:49 +0400, Hans Reiser said:
>
>  
>
>>>Why not just run 'badblocks' (or the failure mechanism which now 
>>>aborts with "bread: Cannot read a block") as an (optional) part of 
>>>fsck and use the output in a bad-block-marking phase? 
>>>      
>>>
>>This is good UI design.  Vitaly....
>>    
>>
>
>Certainly make it optional (or optionally disabled) - having to read 300G of
>data blocks when you know that the media is good would be massive overkill,
>when you're rebooting after a panic for other reasons. ;)
>  
>
The user should be interactively queried as to whether to do it.

Re: Corruption: --fix-fixable results in all nlink values = 0

[Vitaly Fertman]

Hans Reiser wrote:
> Gerrit Hannaert wrote:
> > Hans Reiser wrote:
> >> It is not that I oppose putting it into the tree with a fixed key for
> >> the file holding it, it is that I want us to work on other things
> >> instead.
> >>
> >> Hans
> >
> > Why not just run 'badblocks' (or the failure mechanism which now
> > aborts with "bread: Cannot read a block") as an (optional) part of
> > fsck and use the output in a bad-block-marking phase?
>
> This is good UI design.  Vitaly....

some block could be read at the fifth attempt, so badblocks may show 
different results every time, but you want such blocks to be marked 
as bad all the time.

> > Then you don't need to store the list of bad blocks anywhere, at least
> > not for fsck anyway ;-). Personally though, as a user, I'd like to
> > confirm the list of bad blocks in this case (in case it's too large I
> > might decide not to do it...)
> >
> > It wasn't even clear to me until last week that the hard disk *also*
> > did remapping of bad blocks, whether automatically or with some
> > vendor-tool. Perhaps any fsck failure due to hardware error should
> > recommend using low-level disk-checking tools provided by hard disk
> > vendors prior to taking any action itself?
> >
> > - Gerrit

reiserprogs know how to do the following (disabled for now):
1) reiserfsck --check -B badblocks_file 
checks that blocks from the badblocks_file are not used by an internal 
tree, except the object [-1 -1] and all of these blocks exist as 
unformatted pointers in the object [-1 -1] and all of them are marked 
as used in on-disk bitmap.
2) reiserfsck --fix-fixable -B badblocks_file
checks that blocks from the badblocks_file are not used by an internal 
tree, remove the body of the object [-1 -1] and add all blocks from the 
file badblocks_file into the object [-1 -1] as unformatted pointers.
3) reiserfsck --rebuild-tree -B badblocks_file
rebuilds an internal tree without pointers to blocks specified in the 
file badblocks_file, removes the body of the object [-1 -1], add all 
blocks from the file badblocks_file into the file [-1 -1] when the tree 
is rebuilt.
4) debugreiserfs -B badblocks_file
searches the key [-1 -1 1 IND] in the internal tree and prints the bad 
block list kept there.

bad blocks are kept in the object [-1 -1] as unformatted pointers of 
indirect items. 

-- 

Thanks,
Vitaly Fertman

Re: Corruption: --fix-fixable results in all nlink values = 0

[Chris Mason]

On Thu, 2002-08-22 at 07:00, Vitaly Fertman wrote:

> bad blocks are kept in the object [-1 -1] as unformatted pointers of 
> indirect items. 

And this does not intefere with the savelink code on older kernels?

-chris

Re: Corruption: --fix-fixable results in all nlink values = 0

[Oleg Drokin]

Hello!

On Thu, Aug 22, 2002 at 08:55:38AM -0400, Chris Mason wrote:
> > bad blocks are kept in the object [-1 -1] as unformatted pointers of 
> > indirect items. 
> And this does not intefere with the savelink code on older kernels?

It does, as I explained, this is disabled because it clases with savelinks.

Bye,
    Oleg

Re: Corruption: --fix-fixable results in all nlink values = 0

[Hans Reiser]

Oleg Drokin wrote:

>Hello!
>
>On Thu, Aug 22, 2002 at 08:55:38AM -0400, Chris Mason wrote:
>  
>
>>>bad blocks are kept in the object [-1 -1] as unformatted pointers of 
>>>indirect items. 
>>>      
>>>
>>And this does not intefere with the savelink code on older kernels?
>>    
>>
>
>It does, as I explained, this is disabled because it clases with savelinks.
>
>Bye,
>    Oleg
>
>
>  
>
What is the fixit plan?

Re: Corruption: --fix-fixable results in all nlink values = 0

[Oleg Drokin]

Hello!

On Thu, Aug 22, 2002 at 08:42:29PM +0400, Hans Reiser wrote:

> >>>bad blocks are kept in the object [-1 -1] as unformatted pointers of 
> >>>indirect items. 
> >>And this does not intefere with the savelink code on older kernels?
> >It does, as I explained, this is disabled because it clases with savelinks.
> What is the fixit plan?

You demanded that no badblocks info should be stored in the tree, so we will
drop that bit of code completely, it seems.

Bye,
    Oleg

Re: Corruption: --fix-fixable results in all nlink values = 0

[Hans Reiser]

Oleg Drokin wrote:

>Hello!
>
>On Thu, Aug 22, 2002 at 08:42:29PM +0400, Hans Reiser wrote:
>
>  
>
>>>>>bad blocks are kept in the object [-1 -1] as unformatted pointers of 
>>>>>indirect items. 
>>>>>          
>>>>>
>>>>And this does not intefere with the savelink code on older kernels?
>>>>        
>>>>
>>>It does, as I explained, this is disabled because it clases with savelinks.
>>>      
>>>
>>What is the fixit plan?
>>    
>>
>
>You demanded that no badblocks info should be stored in the tree, so we will
>drop that bit of code completely, it seems.
>
>Bye,
>    Oleg
>
>
>  
>
Since the code already exists, maybe you should just change the reserved 
key for it.

Re: Corruption: --fix-fixable results in all nlink values = 0

[Oleg Drokin]

Hello!

On Fri, Aug 23, 2002 at 02:53:07PM +0400, Hans Reiser wrote:

> >>What is the fixit plan?
> >You demanded that no badblocks info should be stored in the tree, so we 
> >will
> >drop that bit of code completely, it seems.
> Since the code already exists, maybe you should just change the reserved 
> key for it.

That was my original plan. We still can get back to it, if you want.

Bye,
    Oleg

Re: Corruption: --fix-fixable results in all nlink values = 0

[Hans Reiser]

Oleg Drokin wrote:

>Hello!
>
>On Fri, Aug 23, 2002 at 02:53:07PM +0400, Hans Reiser wrote:
>
>  
>
>>>>What is the fixit plan?
>>>>        
>>>>
>>>You demanded that no badblocks info should be stored in the tree, so we 
>>>will
>>>drop that bit of code completely, it seems.
>>>      
>>>
>>Since the code already exists, maybe you should just change the reserved 
>>key for it.
>>    
>>
>
>That was my original plan. We still can get back to it, if you want.
>
>Bye,
>    Oleg
>
>
>  
>
I was just trying to avoid writing additional code.  If there is 
existing code that needs fixing, then fix it.

Hans