From: Jeff Mahoney <jeffm@suse.com>
To: Tom Mortensen <tmmlkml@gmail.com>
Cc: tony@tvortex.net, linux-kernel@vger.kernel.org,
ReiserFS Mailing List <reiserfs-devel@vger.kernel.org>
Subject: Re: reiserfs fs/reiserfs/bitmap.c:1287
Date: Wed, 08 Aug 2007 19:54:20 -0400 [thread overview]
Message-ID: <46BA57AC.2040306@suse.com> (raw)
In-Reply-To: <a52a95e30708081529i7cee02ddq61471378c2a12ffa@mail.gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Tom Mortensen wrote:
> I'm wondering if any resolution to this particular bug? I see this
> exact kernel bug in copying large data sets (40GB+), and can reproduce
> fairly well. Running reiserfsck produces this message:
>
> "Zero bit found in on-disk bitmap after the last valid bit."
BTW, this error describes the following condition:
With a 4KiB blocksize (assumed), each bitmap describes 128MiB chunks. If
your file system is of such a size that it's not an even multiple of
128MiB, the final bitmap will describe blocks that aren't part of the
file system. The easiest way to represent them is to mark them used so
that they won't end up getting allocated, ever.
The message quoted above means that some of the bits that describe the
blocks beyond the end of the file system have been zeroed, indicating
that the space is available. If you were actually hit by this condition
at runtime, you'd get "attempt to access beyond end of device" or
something like that in your log.
In any event, something is corrupting your bitmaps and that needs to get
tracked down. The size of the file system is important. I've been seeing
reports of users hitting similar problems with file systems larger than
8 TiB. The cause is that the s_bmap_nr field in the superblock is 16
bit, and the file system assumes it's correct. mkreiserfs < 3.6.20 will
happily create those file systems with a value that has wrapped, while
mkreiserfs >= 3.6.20 will zero the value out, causing a mount failure
unless the kernel has been patched to support the full size and to
interpret s_bmap_nr == 0 as "value has overflowed."
I've posted some lightly tested versions of patches to handle > 8TiB
file systems on the reiserfs-devel mailing list and hope to finalize
them this week. If your file system isn't larger than 8 TiB, then we'll
have to do a bit more hunting.
- -Jeff
- --
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFGulesLPWxlyuTD7IRAsK2AJ9hHXP/u/U39ilYbJzuJZH1Ak7n3ACfb/Oo
2GIGKznayXqevH6lVGh8vew=
=q4Ca
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2007-08-08 23:53 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-12 17:27 reiserfs fs/reiserfs/bitmap.c:1287 Anthony Simons
2007-07-12 19:14 ` Jeff Mahoney
2007-08-08 22:29 ` Tom Mortensen
2007-08-08 23:43 ` Jeff Mahoney
2007-08-08 23:54 ` Jeff Mahoney [this message]
2007-08-09 17:55 ` Tom Mortensen
2007-08-09 18:18 ` Tom Mortensen
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=46BA57AC.2040306@suse.com \
--to=jeffm@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=reiserfs-devel@vger.kernel.org \
--cc=tmmlkml@gmail.com \
--cc=tony@tvortex.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox