Re: reiserfs fs/reiserfs/bitmap.c:1287

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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  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:
> 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
> Version: GnuPG v2.0.4-svn0 (GNU/Linux)
> Comment: Using GnuPG with SUSE -
> iD8DBQFGulesLPWxlyuTD7IRAsK2AJ9hHXP/u/U39ilYbJzuJZH1Ak7n3ACfb/Oo
> 2GIGKznayXqevH6lVGh8vew=
> =q4Ca
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at
Please read the FAQ at

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux