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@xxxxxxxx> 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 reiserfs-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
