All of lore.kernel.org
 help / color / mirror / Atom feed
* --rebuild-tree always finds errors --check is ok
@ 2004-12-31  5:35 hanasaki
  0 siblings, 0 replies; 8+ messages in thread
From: hanasaki @ 2004-12-31  5:35 UTC (permalink / raw)
  To: reiserfs-list

Running reiser3 on kernel 2.6.10 and 2.6.9 with Debian sarge and unstable.

the --rebuild-tree always finds errors and corrects them.  even when run 
more than once consecutively without mounting the partition in between.

--check says all is good.



^ permalink raw reply	[flat|nested] 8+ messages in thread

* --rebuild-tree always finds errors --check is ok
@ 2005-01-01 21:55 hanasaki
  2005-01-04 14:30 ` Vladimir Saveliev
  0 siblings, 1 reply; 8+ messages in thread
From: hanasaki @ 2005-01-01 21:55 UTC (permalink / raw)
  To: reiserfs-list

Running reiser3 on kernel 2.6.10 and 2.6.9 with Debian sarge and unstable.

the --rebuild-tree always finds errors and corrects them.  even when run
more than once consecutively without mounting the partition in between.

--check says all is good.




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: --rebuild-tree always finds errors --check is ok
  2005-01-01 21:55 --rebuild-tree always finds errors --check is ok hanasaki
@ 2005-01-04 14:30 ` Vladimir Saveliev
  2005-01-04 17:25   ` hanasaki
  0 siblings, 1 reply; 8+ messages in thread
From: Vladimir Saveliev @ 2005-01-04 14:30 UTC (permalink / raw)
  To: hanasaki; +Cc: reiserfs-list

Hello

On Sun, 2005-01-02 at 00:55, hanasaki wrote:
> Running reiser3 on kernel 2.6.10 and 2.6.9 with Debian sarge and unstable.
> 
> the --rebuild-tree always finds errors and corrects them.  even when run
> more than once consecutively without mounting the partition in between.
> 
Please provide reiserfsck --rebuild-tree output.
What is version of your reiserfsck? (reiserfsck -V)

> --check says all is good.
> 
> 
> 
> 


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: --rebuild-tree always finds errors --check is ok
  2005-01-04 14:30 ` Vladimir Saveliev
@ 2005-01-04 17:25   ` hanasaki
  2005-01-06 12:06     ` Vladimir Saveliev
  2005-01-07 20:43     ` Vitaly Fertman
  0 siblings, 2 replies; 8+ messages in thread
From: hanasaki @ 2005-01-04 17:25 UTC (permalink / raw)
  To: Vladimir Saveliev; +Cc: reiserfs-list

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

Version of reiserfsk
======================
== From debian sarge
/sbin/reiserfsck -V
reiserfsck 3.6.19 (2003 www.namesys.com)
== also used the version in knoppix 3.7 with similar results

the output of two consecutive runs of --rebuild-tree on the same 
unmounted partition are attached.  Below is the diff

diff data00-run1 data00-run0
14c14
< 172168 directory entries were hashed with "r5" hash.
---
 > 172167 directory entries were hashed with "r5" hash.


Vladimir Saveliev wrote:
> Hello
> 
> On Sun, 2005-01-02 at 00:55, hanasaki wrote:
> 
>>Running reiser3 on kernel 2.6.10 and 2.6.9 with Debian sarge and unstable.
>>
>>the --rebuild-tree always finds errors and corrects them.  even when run
>>more than once consecutively without mounting the partition in between.
>>
> 
> Please provide reiserfsck --rebuild-tree output.
> What is version of your reiserfsck? (reiserfsck -V)
> 
> 
>>--check says all is good.
>>
>>
>>
>>
> 
> 


[-- Attachment #2: data00-run0 --]
[-- Type: text/plain, Size: 1195 bytes --]

####### Pass 0 #######
block 254411: The number of items (21) is incorrect, should be (1) - corrected
block 254411: The free space (1) is incorrect, should be (2256) - corrected
pass0: vpf-10110: block 254411, item (0): Unknown item type found [0 251658496 0x1001800 ??? (15)] - deleted
block 1574493: The number of items (18) is incorrect, should be (0) - corrected
block 1574493: The free space (1184) is incorrect, should be (4072) - corrected
block 2206239: The number of items (1) is incorrect, should be (0) - corrected
block 2206239: The free space (0) is incorrect, should be (4072) - corrected
block 2844875: The number of items (2) is incorrect, should be (1) - corrected
block 2844875: The free space (0) is incorrect, should be (4048) - corrected
pass0: vpf-10110: block 2844875, item (0): Unknown item type found [16777472 16780544 0x200 ??? (15)] - deleted
block 3326501: The number of items (1) is incorrect, should be (0) - corrected
block 3326501: The free space (0) is incorrect, should be (4072) - corrected
172167 directory entries were hashed with "r5" hash.
####### Pass 1 #######
####### Pass 2 #######
####### Pass 3 #########
####### Pass 3a (lost+found pass) #########

[-- Attachment #3: data00-run1 --]
[-- Type: text/plain, Size: 1195 bytes --]

####### Pass 0 #######
block 254411: The number of items (21) is incorrect, should be (1) - corrected
block 254411: The free space (1) is incorrect, should be (2256) - corrected
pass0: vpf-10110: block 254411, item (0): Unknown item type found [0 251658496 0x1001800 ??? (15)] - deleted
block 1574493: The number of items (18) is incorrect, should be (0) - corrected
block 1574493: The free space (1184) is incorrect, should be (4072) - corrected
block 2206239: The number of items (1) is incorrect, should be (0) - corrected
block 2206239: The free space (0) is incorrect, should be (4072) - corrected
block 2844875: The number of items (2) is incorrect, should be (1) - corrected
block 2844875: The free space (0) is incorrect, should be (4048) - corrected
pass0: vpf-10110: block 2844875, item (0): Unknown item type found [16777472 16780544 0x200 ??? (15)] - deleted
block 3326501: The number of items (1) is incorrect, should be (0) - corrected
block 3326501: The free space (0) is incorrect, should be (4072) - corrected
172168 directory entries were hashed with "r5" hash.
####### Pass 1 #######
####### Pass 2 #######
####### Pass 3 #########
####### Pass 3a (lost+found pass) #########

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: --rebuild-tree always finds errors --check is ok
  2005-01-04 17:25   ` hanasaki
@ 2005-01-06 12:06     ` Vladimir Saveliev
  2005-01-07 20:43     ` Vitaly Fertman
  1 sibling, 0 replies; 8+ messages in thread
From: Vladimir Saveliev @ 2005-01-06 12:06 UTC (permalink / raw)
  To: hanasaki; +Cc: reiserfs-list

Hello

On Tue, 2005-01-04 at 20:25, hanasaki wrote:
> Version of reiserfsk
> ======================
> == From debian sarge
> /sbin/reiserfsck -V
> reiserfsck 3.6.19 (2003 www.namesys.com)
> == also used the version in knoppix 3.7 with similar results
> 
> the output of two consecutive runs of --rebuild-tree on the same 
> unmounted partition are attached.  Below is the diff
> 
> diff data00-run1 data00-run0
> 14c14
> < 172168 directory entries were hashed with "r5" hash.
> ---
>  > 172167 directory entries were hashed with "r5" hash.
> 
> 
> Vladimir Saveliev wrote:
> > Hello
> > 
> > On Sun, 2005-01-02 at 00:55, hanasaki wrote:
> > 
> >>Running reiser3 on kernel 2.6.10 and 2.6.9 with Debian sarge and unstable.
> >>
> >>the --rebuild-tree always finds errors and corrects them.  even when run
> >>more than once consecutively without mounting the partition in between.
> >>
> > 
> > Please provide reiserfsck --rebuild-tree output.
> > What is version of your reiserfsck? (reiserfsck -V)
> > 
> > 
> >>--check says all is good.
> >>
> >>
> >>
> >>
> > 
> > 
> 
> 
> ______________________________________________________________________
> ####### Pass 0 #######
> block 254411: The number of items (21) is incorrect, should be (1) - corrected
> block 254411: The free space (1) is incorrect, should be (2256) - corrected
> pass0: vpf-10110: block 254411, item (0): Unknown item type found [0 251658496 0x1001800 ??? (15)] - deleted
> block 1574493: The number of items (18) is incorrect, should be (0) - corrected
> block 1574493: The free space (1184) is incorrect, should be (4072) - corrected
> block 2206239: The number of items (1) is incorrect, should be (0) - corrected
> block 2206239: The free space (0) is incorrect, should be (4072) - corrected
> block 2844875: The number of items (2) is incorrect, should be (1) - corrected
> block 2844875: The free space (0) is incorrect, should be (4048) - corrected
> pass0: vpf-10110: block 2844875, item (0): Unknown item type found [16777472 16780544 0x200 ??? (15)] - deleted
> block 3326501: The number of items (1) is incorrect, should be (0) - corrected
> block 3326501: The free space (0) is incorrect, should be (4072) - corrected
> 172167 directory entries were hashed with "r5" hash.
> ####### Pass 1 #######
> ####### Pass 2 #######
> ####### Pass 3 #########
> ####### Pass 3a (lost+found pass) #########
> 
> ______________________________________________________________________
> ####### Pass 0 #######
> block 254411: The number of items (21) is incorrect, should be (1) - corrected
> block 254411: The free space (1) is incorrect, should be (2256) - corrected
> pass0: vpf-10110: block 254411, item (0): Unknown item type found [0 251658496 0x1001800 ??? (15)] - deleted
> block 1574493: The number of items (18) is incorrect, should be (0) - corrected
> block 1574493: The free space (1184) is incorrect, should be (4072) - corrected
> block 2206239: The number of items (1) is incorrect, should be (0) - corrected
> block 2206239: The free space (0) is incorrect, should be (4072) - corrected
> block 2844875: The number of items (2) is incorrect, should be (1) - corrected
> block 2844875: The free space (0) is incorrect, should be (4048) - corrected
> pass0: vpf-10110: block 2844875, item (0): Unknown item type found [16777472 16780544 0x200 ??? (15)] - deleted
> block 3326501: The number of items (1) is incorrect, should be (0) - corrected
> block 3326501: The free space (0) is incorrect, should be (4072) - corrected
> 172168 directory entries were hashed with "r5" hash.
> ####### Pass 1 #######
> ####### Pass 2 #######
> ####### Pass 3 #########
> ####### Pass 3a (lost+found pass) #########

Can you do:
debugreiserfs -p that-device | gzip -c > fs.gz and make fs.gz
downloadable. That would allow us to fix reiserfsck bug faster.



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: --rebuild-tree always finds errors --check is ok
  2005-01-04 17:25   ` hanasaki
  2005-01-06 12:06     ` Vladimir Saveliev
@ 2005-01-07 20:43     ` Vitaly Fertman
  2005-01-08  0:44       ` hanasaki
  1 sibling, 1 reply; 8+ messages in thread
From: Vitaly Fertman @ 2005-01-07 20:43 UTC (permalink / raw)
  To: hanasaki, Vladimir Saveliev; +Cc: reiserfs-list

On Tuesday 04 January 2005 20:25, hanasaki wrote:
> Version of reiserfsk
> ======================
> == From debian sarge
> /sbin/reiserfsck -V
> reiserfsck 3.6.19 (2003 www.namesys.com)
> == also used the version in knoppix 3.7 with similar results
>
> the output of two consecutive runs of --rebuild-tree on the same
> unmounted partition are attached.  Below is the diff

rebuild-tree finds some blocks that looks like reiserfs formatted 
blocks for the first sight whereas they are not and just belongs to 
some file bodies. The consistency check reveals no valid metadata 
in them, so they are considered as not valid reiserfs formatted blocks
and left not modified on disk. This is why the second run of rebuild-tree
finds them again and tries to do all the stuff again.

-- 
Thanks,
Vitaly Fertman


> diff data00-run1 data00-run0
> 14c14
> < 172168 directory entries were hashed with "r5" hash.
> ---
>
>  > 172167 directory entries were hashed with "r5" hash.
>
> Vladimir Saveliev wrote:
> > Hello
> >
> > On Sun, 2005-01-02 at 00:55, hanasaki wrote:
> >>Running reiser3 on kernel 2.6.10 and 2.6.9 with Debian sarge and
> >> unstable.
> >>
> >>the --rebuild-tree always finds errors and corrects them.  even when run
> >>more than once consecutively without mounting the partition in between.
> >
> > Please provide reiserfsck --rebuild-tree output.
> > What is version of your reiserfsck? (reiserfsck -V)
> >
> >>--check says all is good.



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: --rebuild-tree always finds errors --check is ok
  2005-01-07 20:43     ` Vitaly Fertman
@ 2005-01-08  0:44       ` hanasaki
  2005-01-10 12:50         ` Vitaly Fertman
  0 siblings, 1 reply; 8+ messages in thread
From: hanasaki @ 2005-01-08  0:44 UTC (permalink / raw)
  To: reiserfs-list

Could you outline exactly what takes place on a rebuild-tree?

I was under the incorrect assumption that if a rebuild-tree is 100% 
successful then the FS is ok and a subsequent rebuild-tree will have 
nothing to fix/report.  .....

Vitaly Fertman wrote:
> On Tuesday 04 January 2005 20:25, hanasaki wrote:
> 
>>Version of reiserfsk
>>======================
>>== From debian sarge
>>/sbin/reiserfsck -V
>>reiserfsck 3.6.19 (2003 www.namesys.com)
>>== also used the version in knoppix 3.7 with similar results
>>
>>the output of two consecutive runs of --rebuild-tree on the same
>>unmounted partition are attached.  Below is the diff
> 
> 
> rebuild-tree finds some blocks that looks like reiserfs formatted 
> blocks for the first sight whereas they are not and just belongs to 
> some file bodies. The consistency check reveals no valid metadata 
> in them, so they are considered as not valid reiserfs formatted blocks
> and left not modified on disk. This is why the second run of rebuild-tree
> finds them again and tries to do all the stuff again.
> 

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: --rebuild-tree always finds errors --check is ok
  2005-01-08  0:44       ` hanasaki
@ 2005-01-10 12:50         ` Vitaly Fertman
  0 siblings, 0 replies; 8+ messages in thread
From: Vitaly Fertman @ 2005-01-10 12:50 UTC (permalink / raw)
  To: hanasaki, reiserfs-list

On Saturday 08 January 2005 03:44, hanasaki wrote:
> Could you outline exactly what takes place on a rebuild-tree?

reiserfs has two types of blocks. There are unformatted nodes. They
contain plain user file data. And there are formatted nodes. These may 
contain both user file data and filesystem metadata. --rebuild-tree scans
all blocks looking for filesystem metadata, e.g. for formatted nodes. 
However you can put a reiserfs image into a file, then file data (e.g. 
unformatted nodes of the host fs) will contain formatted nodes of the 
fs image, and rebuilding of the host fs will be screwed up as there is 
no way to distinguish image fs metadata kept in unformatted nodes 
of the host fs from the host fs metadata.

> I was under the incorrect assumption that if a rebuild-tree is 100%
> successful then the FS is ok and a subsequent rebuild-tree will have
> nothing to fix/report.  .....

In your case, some unformatted nodes look like formatted ones for the 
first sight, however after fixing all the corruptions in these nodes fsck 
realises that there is no valid metadata left and that they are either 
completely broken nodes or file data ones. To not corrupt file data fsck 
does not flush the made changes on disk. And as nothing gets changed 
the same attempt of fixing these nodes repeats again on the next rebuild.

> Vitaly Fertman wrote:
> > On Tuesday 04 January 2005 20:25, hanasaki wrote:
> >>Version of reiserfsk
> >>======================
> >>== From debian sarge
> >>/sbin/reiserfsck -V
> >>reiserfsck 3.6.19 (2003 www.namesys.com)
> >>== also used the version in knoppix 3.7 with similar results
> >>
> >>the output of two consecutive runs of --rebuild-tree on the same
> >>unmounted partition are attached.  Below is the diff
> >
> > rebuild-tree finds some blocks that looks like reiserfs formatted
> > blocks for the first sight whereas they are not and just belongs to
> > some file bodies. The consistency check reveals no valid metadata
> > in them, so they are considered as not valid reiserfs formatted blocks
> > and left not modified on disk. This is why the second run of rebuild-tree
> > finds them again and tries to do all the stuff again.

-- 
Thanks,
Vitaly Fertman



^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2005-01-10 12:50 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-01-01 21:55 --rebuild-tree always finds errors --check is ok hanasaki
2005-01-04 14:30 ` Vladimir Saveliev
2005-01-04 17:25   ` hanasaki
2005-01-06 12:06     ` Vladimir Saveliev
2005-01-07 20:43     ` Vitaly Fertman
2005-01-08  0:44       ` hanasaki
2005-01-10 12:50         ` Vitaly Fertman
  -- strict thread matches above, loose matches on Subject: below --
2004-12-31  5:35 hanasaki

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.