Zero Bit found

Zero Bit found

[Horst Simon]

Hi,

I recently added a 200GB Seagate IDE drive to my system on a build-in
promise controller on an ASUS A7V, updated BIOS which supports large
disk drives.
The O/S is United Linux 1.0 with the latest patches and the kernel
version is
2.4.21 with latest United Linux patches. The reiserfs is 3.6. During the
initial
setup and first reboot no reiserfsck errors are report. After writing
data to the disk I get now following reiserfsck messages during each
boot:

 ZERO BIT FOUND IN ON-DISK BITMAP AFTER THE LAST VALID BIT
Switching to --fix-fixable mode
Checking

It displays directory paths which it is checking and after finishing
following message is displayed:

The on-disk and the correct bitmaps differ. Will be fixed later

No corruption found

There are on the filesystem:

    Leaves 20264

      Internal nodes 125

        Directories 2063

  Other files 22869

 Data block pointers 15940960 (0 of them are zero)

 Safe links 0

###########

What is this ZERO BIT, is this a serious problem? What could be wrong
bad BIOS, reiserfs, etc.?

Regards,
Horst

Re: Zero Bit found

[Vladimir V. Saveliev]

Hello

Horst Simon wrote:
> Hi,
> 
> I recently added a 200GB Seagate IDE drive to my system on a build-in
> promise controller on an ASUS A7V, updated BIOS which supports large
> disk drives.
> The O/S is United Linux 1.0 with the latest patches and the kernel
> version is
> 2.4.21 with latest United Linux patches. The reiserfs is 3.6. During the
> initial
> setup and first reboot no reiserfsck errors are report. After writing
> data to the disk I get now following reiserfsck messages during each
> boot:
> 
>  ZERO BIT FOUND IN ON-DISK BITMAP AFTER THE LAST VALID BIT
> Switching to --fix-fixable mode
> Checking
> 
> It displays directory paths which it is checking and after finishing
> following message is displayed:
> 
> The on-disk and the correct bitmaps differ. Will be fixed later
> 
> No corruption found
> 
> There are on the filesystem:
> 
>     Leaves 20264
> 
>       Internal nodes 125
> 
>         Directories 2063
> 
>   Other files 22869
> 
>  Data block pointers 15940960 (0 of them are zero)
> 
>  Safe links 0
> 
> ###########
> 
> What is this ZERO BIT, is this a serious problem? 

No, it is not. Reiserfs manages disk space by bitmaps. Those bitmaps are stored in disk blocks.
Reiserfsck expects last bitmap to be filled by 1s in the area which address blocks out of device.
Somehow you got that padding area in last bitmap incorrectly initialized.
It is completely harmless.

What could be wrong
> bad BIOS, reiserfs, etc.?
> 

What version of reiserfsprogs you are using?


> Regards,
> Horst
> 
> 
> 
> 

Re: Zero Bit found

[Horst Simon]

On Jul 26, 2004 08:08 PM, Vladimir V. Saveliev <vs@namesys.com> wrote:

> Hello
> 
> Horst Simon wrote:
> > Hi,
> > 
> > I recently added a 200GB Seagate IDE drive to my system on a
> > build-in
> > promise controller on an ASUS A7V, updated BIOS which supports large
> > disk drives.
> > The O/S is United Linux 1.0 with the latest patches and the kernel
> > version is
> > 2.4.21 with latest United Linux patches. The reiserfs is 3.6. During
> > the
> > initial
> > setup and first reboot no reiserfsck errors are report. After
> > writing
> > data to the disk I get now following reiserfsck messages during each
> > boot:
> > 
> >  ZERO BIT FOUND IN ON-DISK BITMAP AFTER THE LAST VALID BIT
> > Switching to --fix-fixable mode
> > Checking
> > 
> > It displays directory paths which it is checking and after finishing
> > following message is displayed:
> > 
> > The on-disk and the correct bitmaps differ. Will be fixed later
> > 
> > No corruption found
> > 
> > There are on the filesystem:
> > 
> >     Leaves 20264
> > 
> >       Internal nodes 125
> > 
> >         Directories 2063
> > 
> >   Other files 22869
> > 
> >  Data block pointers 15940960 (0 of them are zero)
> > 
> >  Safe links 0
> > 
> > ###########
> > 
> > What is this ZERO BIT, is this a serious problem? 
> 
> No, it is not. Reiserfs manages disk space by bitmaps. Those bitmaps
> are stored in disk blocks.
> Reiserfsck expects last bitmap to be filled by 1s in the area which
> address blocks out of device.
> Somehow you got that padding area in last bitmap incorrectly
> initialized.
> It is completely harmless.
> 
> What could be wrong
> > bad BIOS, reiserfs, etc.?
> > 
> 
> What version of reiserfsprogs you are using?
> 
> 
> > Regards,
> > Horst
> > 
Thanks for the information, the reiserfsprogs are 3.6.17. On the weekend
I will
try the suggestions from Vitaly Fertman. I noticed that this problem
only occured after writing to the disk.

Regards,
Horst

Re: Zero Bit found

[Hans Reiser]

Horst Simon wrote:

>On Jul 26, 2004 08:08 PM, Vladimir V. Saveliev <vs@namesys.com> wrote:
>
>  
>
>>Hello
>>
>>Horst Simon wrote:
>>    
>>
>>>Hi,
>>>
>>>I recently added a 200GB Seagate IDE drive to my system on a
>>>build-in
>>>promise controller on an ASUS A7V, updated BIOS which supports large
>>>disk drives.
>>>The O/S is United Linux 1.0 with the latest patches and the kernel
>>>version is
>>>2.4.21 with latest United Linux patches. The reiserfs is 3.6. During
>>>the
>>>initial
>>>setup and first reboot no reiserfsck errors are report. After
>>>writing
>>>data to the disk I get now following reiserfsck messages during each
>>>boot:
>>>
>>> ZERO BIT FOUND IN ON-DISK BITMAP AFTER THE LAST VALID BIT
>>>Switching to --fix-fixable mode
>>>Checking
>>>
>>>It displays directory paths which it is checking and after finishing
>>>following message is displayed:
>>>
>>>The on-disk and the correct bitmaps differ. Will be fixed later
>>>
>>>No corruption found
>>>
>>>There are on the filesystem:
>>>
>>>    Leaves 20264
>>>
>>>      Internal nodes 125
>>>
>>>        Directories 2063
>>>
>>>  Other files 22869
>>>
>>> Data block pointers 15940960 (0 of them are zero)
>>>
>>> Safe links 0
>>>
>>>###########
>>>
>>>What is this ZERO BIT, is this a serious problem? 
>>>      
>>>
>>No, it is not. Reiserfs manages disk space by bitmaps. Those bitmaps
>>are stored in disk blocks.
>>Reiserfsck expects last bitmap to be filled by 1s in the area which
>>address blocks out of device.
>>Somehow you got that padding area in last bitmap incorrectly
>>initialized.
>>It is completely harmless.
>>
>>What could be wrong
>>    
>>
>>>bad BIOS, reiserfs, etc.?
>>>
>>>      
>>>
>>What version of reiserfsprogs you are using?
>>
>>
>>    
>>
>>>Regards,
>>>Horst
>>>
>>>      
>>>
>Thanks for the information, the reiserfsprogs are 3.6.17. On the weekend
>I will
>try the suggestions from Vitaly Fertman. I noticed that this problem
>only occured after writing to the disk.
>
>Regards,
>Horst
>
>
>
>  
>
Writing in what way?  Usual fs operations, or writing to random blocks 
not via the fs or with something like corrupt partition tables?

(I prefer to think that reiserfs has no bugs that write to random 
blocks.....)

Re: Zero Bit found

[Horst Simon]

On Tue, 27 Jul 2004 05:06 pm, Hans Reiser wrote:
> Horst Simon wrote:
> >On Jul 26, 2004 08:08 PM, Vladimir V. Saveliev <vs@namesys.com> wrote:
> >>Hello
> >>
> >>Horst Simon wrote:
> >>>Hi,
> >>>
> >>>I recently added a 200GB Seagate IDE drive to my system on a
> >>>build-in
> >>>promise controller on an ASUS A7V, updated BIOS which supports large
> >>>disk drives.
> >>>The O/S is United Linux 1.0 with the latest patches and the kernel
> >>>version is
> >>>2.4.21 with latest United Linux patches. The reiserfs is 3.6. During
> >>>the
> >>>initial
> >>>setup and first reboot no reiserfsck errors are report. After
> >>>writing
> >>>data to the disk I get now following reiserfsck messages during each
> >>>boot:
> >>>
> >>> ZERO BIT FOUND IN ON-DISK BITMAP AFTER THE LAST VALID BIT
> >>>Switching to --fix-fixable mode
> >>>Checking
> >>>
> >>>It displays directory paths which it is checking and after finishing
> >>>following message is displayed:
> >>>
> >>>The on-disk and the correct bitmaps differ. Will be fixed later
> >>>
> >>>No corruption found
> >>>
> >>>There are on the filesystem:
> >>>
> >>>    Leaves 20264
> >>>
> >>>      Internal nodes 125
> >>>
> >>>        Directories 2063
> >>>
> >>>  Other files 22869
> >>>
> >>> Data block pointers 15940960 (0 of them are zero)
> >>>
> >>> Safe links 0
> >>>
> >>>###########
> >>>
> >>>What is this ZERO BIT, is this a serious problem?
> >>
> >>No, it is not. Reiserfs manages disk space by bitmaps. Those bitmaps
> >>are stored in disk blocks.
> >>Reiserfsck expects last bitmap to be filled by 1s in the area which
> >>address blocks out of device.
> >>Somehow you got that padding area in last bitmap incorrectly
> >>initialized.
> >>It is completely harmless.
> >>
> >>What could be wrong
> >>
> >>>bad BIOS, reiserfs, etc.?
> >>
> >>What version of reiserfsprogs you are using?
> >>
> >>>Regards,
> >>>Horst
> >
> >Thanks for the information, the reiserfsprogs are 3.6.17. On the weekend
> >I will
> >try the suggestions from Vitaly Fertman. I noticed that this problem
> >only occured after writing to the disk.
> >
> >Regards,
> >Horst
>
> Writing in what way?  Usual fs operations, or writing to random blocks
> not via the fs or with something like corrupt partition tables?
>
> (I prefer to think that reiserfs has no bugs that write to random
> blocks.....)

Just to clarify when copying data to the disk. I suspect now the onboard 
promise controller. On the weekend I will move the disk to an other
system and do more testing.

Regards,
Horst
-- 
E-Mail: hsimon@optusnet.com.au
 Tel: +61(0)3 9553-1624
 Fax: +61(0)3 9553-1624

 This message was sent by
 KMail 1.6.2 Using KDE3.2.1 & SuSE Linux 9.1

Re: Zero Bit found

[Vitaly Fertman]

On Monday 26 July 2004 07:25, Horst Simon wrote:
> Hi,
>
> I recently added a 200GB Seagate IDE drive to my system on a build-in
> promise controller on an ASUS A7V, updated BIOS which supports large
> disk drives.
> The O/S is United Linux 1.0 with the latest patches and the kernel
> version is
> 2.4.21 with latest United Linux patches. The reiserfs is 3.6. During the
> initial
> setup and first reboot no reiserfsck errors are report. After writing
> data to the disk I get now following reiserfsck messages during each
> boot:
>
>  ZERO BIT FOUND IN ON-DISK BITMAP AFTER THE LAST VALID BIT
> Switching to --fix-fixable mode
> Checking
>
> It displays directory paths which it is checking and after finishing
> following message is displayed:
>
> The on-disk and the correct bitmaps differ. Will be fixed later
>
> No corruption found
>
> What is this ZERO BIT, is this a serious problem? What could be wrong

zero bit is not serious, but the message 'The on-disk and the correct bitmaps 
differ. ' points to another more serious problem. --fix-fixable is supposed to
fix them both (and as I have just tested, it does) -- this is not good that these 
problems arrear again and again.

> bad BIOS, reiserfs, etc.?

could you umount the fs, run reiserfsck --check on it, then if it finds these 
corruptions fix them with fix-fixable and reiserfsck --check again to be
sure all of them are fixed?

the problem could in your hardware also. we deal with such problems 
under the terms of our support page (www.namesys.com/support.html) 
-- visit it please.

-- 
Thanks,
Vitaly Fertman

Re: Zero Bit found

[Vitaly Fertman]

On Monday 26 July 2004 14:15, Vitaly Fertman wrote:
> On Monday 26 July 2004 07:25, Horst Simon wrote:
> > Hi,
> >
> > I recently added a 200GB Seagate IDE drive to my system on a build-in
> > promise controller on an ASUS A7V, updated BIOS which supports large
> > disk drives.
> > The O/S is United Linux 1.0 with the latest patches and the kernel
> > version is
> > 2.4.21 with latest United Linux patches. The reiserfs is 3.6. During the
> > initial
> > setup and first reboot no reiserfsck errors are report. After writing
> > data to the disk I get now following reiserfsck messages during each
> > boot:
> >
> >  ZERO BIT FOUND IN ON-DISK BITMAP AFTER THE LAST VALID BIT
> > Switching to --fix-fixable mode
> > Checking
> >
> > It displays directory paths which it is checking and after finishing
> > following message is displayed:
> >
> > The on-disk and the correct bitmaps differ. Will be fixed later
> >
> > No corruption found
> >
> > What is this ZERO BIT, is this a serious problem? What could be wrong
>
> zero bit is not serious, but the message 'The on-disk and the correct
> bitmaps differ. ' points to another more serious problem. --fix-fixable is
> supposed to fix them both (and as I have just tested, it does) -- this is
> not good that these problems arrear again and again.

... appear ...

> > bad BIOS, reiserfs, etc.?
>
> could you umount the fs, run reiserfsck --check on it, then if it finds
> these corruptions fix them with fix-fixable and reiserfsck --check again to
> be sure all of them are fixed?
>
> the problem could in your hardware also. we deal with such problems
> under the terms of our support page (www.namesys.com/support.html)
> -- visit it please.

-- 
Thanks,
Vitaly Fertman

Re: Zero Bit found

[Horst Simon]

On Jul 26, 2004 08:15 PM, Vitaly Fertman <vitaly@namesys.com> wrote:

> On Monday 26 July 2004 07:25, Horst Simon wrote:
> > Hi,
> >
> > I recently added a 200GB Seagate IDE drive to my system on a
> > build-in
> > promise controller on an ASUS A7V, updated BIOS which supports large
> > disk drives.
> > The O/S is United Linux 1.0 with the latest patches and the kernel
> > version is
> > 2.4.21 with latest United Linux patches. The reiserfs is 3.6. During
> > the
> > initial
> > setup and first reboot no reiserfsck errors are report. After
> > writing
> > data to the disk I get now following reiserfsck messages during each
> > boot:
> >
> >  ZERO BIT FOUND IN ON-DISK BITMAP AFTER THE LAST VALID BIT
> > Switching to --fix-fixable mode
> > Checking
> >
> > It displays directory paths which it is checking and after finishing
> > following message is displayed:
> >
> > The on-disk and the correct bitmaps differ. Will be fixed later
> >
> > No corruption found
> >
> > What is this ZERO BIT, is this a serious problem? What could be
> > wrong
> 
> zero bit is not serious, but the message 'The on-disk and the correct
> bitmaps
> differ. ' points to another more serious problem. --fix-fixable is
> supposed to
> fix them both (and as I have just tested, it does) -- this is not good
> that these
> problems arrear again and again.
> 
> > bad BIOS, reiserfs, etc.?
> 
> could you umount the fs, run reiserfsck --check on it, then if it
> finds these
> corruptions fix them with fix-fixable and reiserfsck --check again to
> be
> sure all of them are fixed?
> 
> the problem could in your hardware also. we deal with such problems 
> under the terms of our support page (www.namesys.com/support.html) 
> -- visit it please.
> 
> -- 
> Thanks,
> Vitaly Fertman
> 

Thanks for the information, I will try your suggestions coming weekend.
I also
noticed that this problems occur only after writing to the disk. 

Regards,
Horst

Re: Zero Bit found

[Horst Simon]

On Mon, 26 Jul 2004 08:15 pm, Vitaly Fertman wrote:
> On Monday 26 July 2004 07:25, Horst Simon wrote:
> > Hi,
> >
> > I recently added a 200GB Seagate IDE drive to my system on a build-in
> > promise controller on an ASUS A7V, updated BIOS which supports large
> > disk drives.
> > The O/S is United Linux 1.0 with the latest patches and the kernel
> > version is
> > 2.4.21 with latest United Linux patches. The reiserfs is 3.6. During the
> > initial
> > setup and first reboot no reiserfsck errors are report. After writing
> > data to the disk I get now following reiserfsck messages during each
> > boot:
> >
> >  ZERO BIT FOUND IN ON-DISK BITMAP AFTER THE LAST VALID BIT
> > Switching to --fix-fixable mode
> > Checking
> >
> > It displays directory paths which it is checking and after finishing
> > following message is displayed:
> >
> > The on-disk and the correct bitmaps differ. Will be fixed later
> >
> > No corruption found
> >
> > What is this ZERO BIT, is this a serious problem? What could be wrong
>
> zero bit is not serious, but the message 'The on-disk and the correct
> bitmaps differ. ' points to another more serious problem. --fix-fixable is
> supposed to fix them both (and as I have just tested, it does) -- this is
> not good that these problems arrear again and again.
>
> > bad BIOS, reiserfs, etc.?
>
> could you umount the fs, run reiserfsck --check on it, then if it finds
> these corruptions fix them with fix-fixable and reiserfsck --check again to
> be sure all of them are fixed?
>
> the problem could in your hardware also. we deal with such problems
> under the terms of our support page (www.namesys.com/support.html)
> -- visit it please.
I finally got around to do your suggestions I moved the drive to an other 
Motherboard and following are the output of reiserfsck

1. reiserfsck --check
###########
reiserfsck --check started at Tue Aug 10 23:02:06 2004
###########
Replaying journal..
0 transactions replayed
Checking internal tree..finished
Comparing bitmaps..vpf-10640: The on-disk and the correct bitmaps differs.
Checking Semantic tree:
finished
1 found corruptions can be fixed when running with --fix-fixable
###########
reiserfsck finished at Tue Aug 10 23:03:08 2004
###########

2. reiserfsck --fix-fixable
###########
reiserfsck --fix-fixable started at Tue Aug 10 23:07:17 2004
###########
Replaying journal..
0 transactions replayed
Checking internal tree..finished
Comparing bitmaps..vpf-10630: The on-disk and the correct bitmaps differs. 
Will be fixed later.
Checking Semantic tree:
finished
No corruptions found
There are on the filesystem:
        Leaves 20287
        Internal nodes 123
        Directories 2064
        Other files 22888
        Data block pointers 15971390 (0 of them are zero)
        Safe links 0
###########
reiserfsck finished at Tue Aug 10 23:08:35 2004
###########

3. reiserfsck --check


-- Do you want to run this program?[N/Yes] (note need to type Yes if you 
do):Yes
###########
reiserfsck --check started at Tue Aug 10 23:09:20 2004
###########
Replaying journal..
0 transactions replayed
Checking internal tree..finished
Comparing bitmaps..vpf-10640: The on-disk and the correct bitmaps differs.
Checking Semantic tree:
finished
1 found corruptions can be fixed when running with --fix-fixable
###########
reiserfsck finished at Tue Aug 10 23:10:22 2004
###########

The reiserfsck is version 3.6.9 O/S SLOX 4.1 (United Linux) Kernel 2.4.21-238
It happens only on the new Seagate 200GB IDE disk drive on different 
controllers (motherboards).

Regards
Horst Simon

  Horst Simon
  HSC-Consulting Pty. Ltd.
  Tel: +61(0)3 9553-1624
  Fax: +61(0)3 9553-1624
  hsimon@optusnet.com.au
  --------------------------------------------------------------
  This message was sent by
  KMail 1.6.2 Using KDE 3.2.2 & SuSE Linux 9.1