From: Hans Reiser <reiser@namesys.com>
To: hsimon@optusnet.com.au
Cc: "Vladimir V. Saveliev" <vs@namesys.com>, reiserfs-list@namesys.com
Subject: Re: Zero Bit found
Date: Tue, 27 Jul 2004 00:06:47 -0700 [thread overview]
Message-ID: <4105FF07.3080807@namesys.com> (raw)
In-Reply-To: <7295144.1090882775326.SLOX.WebMail.wwwrun@neptune.hsc-consulting.com.au>
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.....)
next prev parent reply other threads:[~2004-07-27 7:06 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-26 3:25 Zero Bit found Horst Simon
2004-07-26 10:08 ` Vladimir V. Saveliev
2004-07-26 22:59 ` Horst Simon
2004-07-27 7:06 ` Hans Reiser [this message]
2004-07-27 10:45 ` Horst Simon
2004-07-26 10:15 ` Vitaly Fertman
2004-07-26 10:16 ` Vitaly Fertman
2004-07-26 23:02 ` Horst Simon
2004-08-10 13:13 ` Horst Simon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4105FF07.3080807@namesys.com \
--to=reiser@namesys.com \
--cc=hsimon@optusnet.com.au \
--cc=reiserfs-list@namesys.com \
--cc=vs@namesys.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.