The hard drive is only 80GB and the ReiserFS file system is on
paritition 1 which spans the entire hard drive.
I recently upgraded to kernel 184.108.40.206. Previously was running 2.4.31
and never encountered this error before.
I'm presently trying to make it fail again to see if I can gather more
information. I can also revert to a previous kernel release (either
2.4.x or 2.6.x), any suggestion?
On 8/8/07, Jeff Mahoney <[email protected]> wrote:
> -----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
> -----END PGP SIGNATURE-----
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Video 4 Linux]
[Linux for the blind]