linux-kernel - Re: reiserfs fs/reiserfs/bitmap.c:1287

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 9 Aug 2007 10:55:56 -0700
From:	"Tom Mortensen" <tmmlkml@...il.com>
To:	"Jeff Mahoney" <jeffm@...e.com>
Cc:	tony@...rtex.net, linux-kernel@...r.kernel.org,
	"ReiserFS Mailing List" <reiserfs-devel@...r.kernel.org>
Subject: Re: reiserfs fs/reiserfs/bitmap.c:1287

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 2.6.22.1.  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 <jeffm@...e.com> 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
>
> iD8DBQFGulesLPWxlyuTD7IRAsK2AJ9hHXP/u/U39ilYbJzuJZH1Ak7n3ACfb/Oo
> 2GIGKznayXqevH6lVGh8vew=
> =q4Ca
> -----END PGP SIGNATURE-----
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/