[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-ext4
Subject:    Re: Serious bug?
From:       Theodore Ts'o <tytso () mit ! edu>
Date:       2012-07-31 22:34:02
Message-ID: 20120731223402.GA3989 () thunk ! org
[Download RAW message or body]

On Tue, Jul 31, 2012 at 04:40:36PM -0500, Eric Sandeen wrote:
> > The problem is that fallocate allocated a large number of blocks, which
> > mke2fs then immediately discarded as its first order of business.
> 
> Hm, then why didn't mkfs.ext4 -K solve the problem....

I wasn't able to replicate it with mkfs.ext4 -K on a 3.2 kernel.

However, with a 3.2 kernel, if you have a pre-existing file1 created
via the fallocate, mke2fs, umount, e2fsck series of commands, the
fallocate command will BUG.  More interestingly, if you have an extent
tree created using a 3.2 kernel, and then mount it on using a 3.5+ext4
patches for 3.6 kernel, it still BUG's.

It dies on line 837 of extent.c:

	len = EXT_LAST_INDEX(curp->p_hdr) - ix + 1;   
	BUG_ON(len < 0);

Obviously, it shouldn't do that, and that is a bug which is upstream
in the latest 3.6-rc0 kernel.  But it only happens on a file system
that had tripped over the 3.2 kernel bug first.  At the very least,
the BUG_ON should be an ext4_error() --- but given that this is a file
system that was given clean bill of health by e2fsck, we should handle
it in a more graceful way.

Of course, it might be a good idea if e2fsck was taught how to clean
up non-standard extent trees that have empty extent tree leaf nodes,
but nevertheless, the kernel *should* be able to handle
non-standard/non-optimal extent tree blocks in a sane fashion.

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]