-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Tom Mortensen wrote:
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-----
-
