Serious bug?

linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed

* Serious bug?
@ 2012-07-31  2:17 Nelson, John R
  2012-07-31  2:29 ` Eric Sandeen
  2012-07-31  2:42 ` Theodore Ts'o
  0 siblings, 2 replies; 6+ messages in thread
From: Nelson, John R @ 2012-07-31  2:17 UTC (permalink / raw)
  To: linux-ext4@vger.kernel.org

Hi,
 I created a big 400GB file image and formatted it with mkfs.ext4. the format failed with

Warning: could not erase sector 2: Attempt to write block to filesystem resulted in short write
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
26214400 inodes, 104857600 blocks
5242880 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
3200 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
        4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
        102400000

Allocating group tables: done                            
Warning: could not read block 0: Attempt to read block from filesystem resulted in short read
Warning: could not erase sector 0: Attempt to write block to filesystem resulted in short write
mkfs.ext4: Attempt to write block to filesystem resulted in short write while zeroing block 104857584 at end of filesystem
Writing inode tables: done                            
Creating journal (32768 blocks): mkfs.ext4: Attempt to write block to filesystem resulted in short write 
        while trying to create journal
john@john-K53E:~$ 

i then checked my dmesg and found error on my sda3 partition
[  119.578077] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 53, depth: 2 pblock 0
[  119.578209] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 54, depth: 2 pblock 0
[  119.578340] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 55, depth: 2 pblock 0
[  119.578449] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 56, depth: 2 pblock 0
[  119.578569] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 57, depth: 2 pblock 0
[  119.578695] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 58, depth: 2 pblock 0
[  119.578827] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 59, depth: 2 pblock 0
[  119.578958] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 60, depth: 2 pblock 0
[  119.579090] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 61, depth: 2 pblock 0
[  119.579221] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 62, depth: 2 pblock 0
[  119.579330] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 63, depth: 2 pblock 0
[  119.579450] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 64, depth: 2 pblock 0
[  119.579576] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 65, depth: 2 pblock 0
[  119.579708] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 66, depth: 2 pblock 0
[  119.579844] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 67, depth: 2 pblock 0
[  119.579977] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 68, depth: 2 pblock 0
[  119.580106] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 69, depth: 2 pblock 0
[  119.580214] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 70, depth: 2 pblock 0
[  119.580332] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 71, depth: 2 pblock 0
[  119.580458] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 72, depth: 2 pblock 0
[  119.580590] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 73, depth: 2 pblock 0
[  119.580731] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 74, depth: 2 pblock 0
[  119.580854] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 75, depth: 2 pblock 0
[  119.580985] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 76, depth: 2 pblock 0
[  119.581116] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 77, depth: 2 pblock 0
[  119.581227] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 78, depth: 2 pblock 0
[  119.581347] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 79, depth: 2 pblock 0
[  119.581473] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 80, depth: 2 pblock 0
[  119.581604] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 81, depth: 2 pblock 0
[  119.581735] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 82, depth: 2 pblock 0
[  119.581844] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 83, depth: 2 pblock 0
[  119.581964] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 84, depth: 2 pblock 0
[  119.582091] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 85, depth: 2 pblock 0
[  119.582222] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 86, depth: 2 pblock 0
[  119.582354] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 87, depth: 2 pblock 0
[  119.582494] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 88, depth: 2 pblock 0
[  119.582594] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 89, depth: 2 pblock 0
[  119.582715] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 90, depth: 2 pblock 0
[  119.582886] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 91, depth: 2 pblock 0
[  119.582986] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 92, depth: 2 pblock 0
[  119.583108] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 93, depth: 2 pblock 0
[  119.583238] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 94, depth: 2 pblock 0
[  119.583368] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 95, depth: 2 pblock 0
[  119.583561] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 96, depth: 2 pblock 0
[  119.583651] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 97, depth: 2 pblock 0
[  119.583802] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 98, depth: 2 pblock 0
[  119.584024] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 99, depth: 2 pblock 0
[  119.584127] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 100, depth: 2 pblock 0
[  119.584252] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 101, depth: 2 pblock 0
[  119.584382] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 102, depth: 2 pblock 0
[  119.584511] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 103, depth: 2 pblock 0
[  119.584620] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 104, depth: 2 pblock 0
[  119.584740] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 105, depth: 2 pblock 0
[  119.584867] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 106, depth: 2 pblock 0
[  119.584998] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 107, depth: 2 pblock 0
[  119.585130] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 108, depth: 2 pblock 0

i deleted the image and rebooted and fsck was forced, but i didnt find any errors. But im not sure why this is happening. and please note this. the iblock in my log continues all the way down to 924.

John Nelson

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Serious bug?
  2012-07-31  2:17 Serious bug? Nelson, John R
@ 2012-07-31  2:29 ` Eric Sandeen
  2012-07-31  2:42 ` Theodore Ts'o
  1 sibling, 0 replies; 6+ messages in thread
From: Eric Sandeen @ 2012-07-31  2:29 UTC (permalink / raw)
  To: Nelson, John R; +Cc: linux-ext4@vger.kernel.org

On 7/30/12 9:17 PM, Nelson, John R wrote:
> Hi,
>  I created a big 400GB file image and formatted it with mkfs.ext4. the format failed with

What kernel are you running on for starters?  And how did you create that file image, is it sparse, preallocated, or pre-written?
 
> Warning: could not erase sector 2: Attempt to write block to filesystem resulted in short write

That's from zap-sector() in main(), happens very early, before much else goes on.

Does mkfs.ext4 -K (to prevent hole punching in the file) succeed?

-Eric

> Filesystem label=
> OS type: Linux
> Block size=4096 (log=2)
> Fragment size=4096 (log=2)
> Stride=0 blocks, Stripe width=0 blocks
> 26214400 inodes, 104857600 blocks
> 5242880 blocks (5.00%) reserved for the super user
> First data block=0
> Maximum filesystem blocks=4294967296
> 3200 block groups
> 32768 blocks per group, 32768 fragments per group
> 8192 inodes per group
> Superblock backups stored on blocks: 
>         32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
>         4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
>         102400000
> 
> Allocating group tables: done                            
> Warning: could not read block 0: Attempt to read block from filesystem resulted in short read
> Warning: could not erase sector 0: Attempt to write block to filesystem resulted in short write
> mkfs.ext4: Attempt to write block to filesystem resulted in short write while zeroing block 104857584 at end of filesystem
> Writing inode tables: done                            
> Creating journal (32768 blocks): mkfs.ext4: Attempt to write block to filesystem resulted in short write 
>         while trying to create journal
> john@john-K53E:~$ 
> 
> i then checked my dmesg and found error on my sda3 partition
> [  119.578077] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 53, depth: 2 pblock 0

snip

> [  119.585130] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 108, depth: 2 pblock 0
> 
> i deleted the image and rebooted and fsck was forced, but i didnt find any errors. But im not sure why this is happening. and please note this. the iblock in my log continues all the way down to 924.
> 
> John Nelson
> --
> 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
> 


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Serious bug?
  2012-07-31  2:17 Serious bug? Nelson, John R
  2012-07-31  2:29 ` Eric Sandeen
@ 2012-07-31  2:42 ` Theodore Ts'o
       [not found]   ` <0408C81F72528E40A0D3235A1F67FFC804A643@SN2PRD0202MB144.namprd02.prod.outlook.com>
  1 sibling, 1 reply; 6+ messages in thread
From: Theodore Ts'o @ 2012-07-31  2:42 UTC (permalink / raw)
  To: Nelson, John R; +Cc: linux-ext4@vger.kernel.org

On Tue, Jul 31, 2012 at 02:17:03AM +0000, Nelson, John R wrote:
> Hi,
>  I created a big 400GB file image and formatted it with mkfs.ext4. the format failed with
> 
> Warning: could not erase sector 2: Attempt to write block to filesystem resulted in short write
>
> i then checked my dmesg and found error on my sda3 partition
> [  119.578077] EXT4-fs error (device sda3): ext4_ext_map_blocks:3769: inode #32243725: comm mkfs.ext4: bad extent address lblock: 53, depth: 2 pblock 0

All of the errors indicate that an extent tree block in inode
#32243725 was corrupted.  When you deleted the image file, that
destroyed the evidence, so that's why fsck didn't reveal any problems.

In terms of how and why the extent tree block got corrupted, that is a
mystery.  It could have been a memory corruption, due to hardware or
software bug in the kernel.  It could be a disk corruption, again due
to hardware or software bug.

So we can note what happened, and see if we see anything else similar,
ut unless you can replicate it, I'm not sure we can do much more at
the moment.

Regardless, thank you for the report.   We'll keep an eye out....

	    	      	      		      - Ted

^ permalink raw reply	[flat|nested] 6+ messages in thread

[parent not found: <0408C81F72528E40A0D3235A1F67FFC804A643@SN2PRD0202MB144.namprd02.prod.outlook.com>]

[parent not found: <20120731032536.GE5027@thunk.org>]

[parent not found: <0408C81F72528E40A0D3235A1F67FFC804A65F@SN2PRD0202MB144.namprd02.prod.outlook.com>]

* Re: Serious bug?
       [not found]       ` <0408C81F72528E40A0D3235A1F67FFC804A65F@SN2PRD0202MB144.namprd02.prod.outlook.com>
@ 2012-07-31 21:38         ` Theodore Ts'o
  2012-07-31 21:40           ` Eric Sandeen
  0 siblings, 1 reply; 6+ messages in thread
From: Theodore Ts'o @ 2012-07-31 21:38 UTC (permalink / raw)
  To: Nelson, John R; +Cc: linux-ext4

On Tue, Jul 31, 2012 at 04:54:42AM +0000, Nelson, John R wrote:
> ok i am using 3.2.0-27-generic (ubuntu 64 bit) e2fsporgs 1.42. the filesystem is 681GB.  Both computers are intel based on is core i5 and one is intel atom and they are in no special configuration just one sata cable to each drive
> 
> here are the steps i did
> 1. fallocate file1 -l 500gb              << exact method
> 2.mkfs.ext4 file1                                <<  exact method
> i will get the error messages about it failing, i delete the file and fsck is still forced upon next mount

OK, I see what's going on.  I was able to reproduce it using a 3.2
kernel (but not a more recent kernel which is what I normally use;
more about that later) with a slightly smaller size (since that's all
the space I had on free on my laptop):

# fallocate -l 215g file1
# mke2fs -t ext4 -F file1

The problem is that fallocate allocated a large number of blocks, which
mke2fs then immediately discarded as its first order of business.
This made the fallocate rather pointless, except that it resulted in
an empty extent tree of depth 2.

# debugfs /dev/closure/bigscratch 
debugfs 1.42.5 (29-Jul-2012)
debugfs:  stat file1
Inode: 12   Type: regular    Mode:  0644   Flags: 0x80000
Generation: 746100356    Version: 0x00000000:00000001
User:     0   Group:     0   Size: 214748364800
File ACL: 0    Directory ACL: 0
Links: 1   Blockcount: 8
Fragment:  Address: 0    Number: 0    Size: 0
 ctime: 0x5018491f:7251aec0 -- Tue Jul 31 17:07:43 2012
 atime: 0x5018491f:3dddf2e0 -- Tue Jul 31 17:07:43 2012
 mtime: 0x5018491f:7251aec0 -- Tue Jul 31 17:07:43 2012
crtime: 0x501848d2:26fabf44 -- Tue Jul 31 17:06:26 2012
Size of extra inode fields: 28
EXTENTS:
(ETB0):33794, (ETB1):55300096
debugfs:  extents file1
Level Entries             Logical            Physical Length Flags
 0/ 2   1/  1 52398080 - 52428799    33794             30720
 1/ 2   1/  0 52398080 - 52428799 55300096             30720
debugfs: quit

E2fsck doesn't detect a problem with this because as far as it is
concerned it is a valid (although granted, very unusual) extent tree
layout.

However, this causes the 3.2 kernel to not handle this situation
correctly, and it throws ext4_error() messages which mark the file
system as containing an error.  However, it appears to be a kernel bug
in the 3.2 kernel.  I just tried to reproduce it using a 3.5 kernel
with the commits that I pushed to the Linus for the 3.6 merge window,
and I was *not* able to reproduce it there.

So it looks like the problem has been fixed upstream.  It would take a
bit more work to figure out (a) whether it's been fixed in the latest
3.2.x stable release, and (b) if not, which 3.x release it was fixed
in, and then narrow it down to a specific commit that needs to be
backported to the 3.2 kernel for Ubuntu.

If you have a support contract with Canonical, I'd suggest complaining
to them; this is the classic sort of thing that distributions get paid
to do.  If you don't, you can either do it yourself, or maybe someone
from the community will do it as they have time.  For your
convenience, I've opened a bug with Canonical:

     https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1031518

(Feel free to confirm the bug, and if you have a support contract,
escalate it and ask them to fix it under the terms of your support
contract.)

In the meantime, let me suggest a workaround:

# rm -f file1; touch file1
# mke2fs -t ext4 -F file1 500g

This is what most of the ext4 developers generally do when they create
file system images.  As you'll see it's faster and more efficient in
terms of space utilization, and will work around the bug in the 3.2
kernel.  As far as whether you're likely to trip over it in practice,
other than your "fallocate followed mke2fs" sequence, I wouldn't know
for sure until the specific fix has been identified, but from what
I've seen, I doubt it's likely to be a common issue in practice.

Regards,

						- Ted

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Serious bug?
  2012-07-31 21:38         ` Theodore Ts'o
@ 2012-07-31 21:40           ` Eric Sandeen
  2012-07-31 22:34             ` Theodore Ts'o
  0 siblings, 1 reply; 6+ messages in thread
From: Eric Sandeen @ 2012-07-31 21:40 UTC (permalink / raw)
  To: Theodore Ts'o; +Cc: Nelson, John R, linux-ext4

On 7/31/12 4:38 PM, Theodore Ts'o wrote:
> On Tue, Jul 31, 2012 at 04:54:42AM +0000, Nelson, John R wrote:
>> ok i am using 3.2.0-27-generic (ubuntu 64 bit) e2fsporgs 1.42. the filesystem is 681GB.  Both computers are intel based on is core i5 and one is intel atom and they are in no special configuration just one sata cable to each drive
>>
>> here are the steps i did
>> 1. fallocate file1 -l 500gb              << exact method
>> 2.mkfs.ext4 file1                                <<  exact method
>> i will get the error messages about it failing, i delete the file and fsck is still forced upon next mount
> 
> OK, I see what's going on.  I was able to reproduce it using a 3.2
> kernel (but not a more recent kernel which is what I normally use;
> more about that later) with a slightly smaller size (since that's all
> the space I had on free on my laptop):
> 
> # fallocate -l 215g file1
> # mke2fs -t ext4 -F file1
> 
> 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....

-Eric

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Serious bug?
  2012-07-31 21:40           ` Eric Sandeen
@ 2012-07-31 22:34             ` Theodore Ts'o
  0 siblings, 0 replies; 6+ messages in thread
From: Theodore Ts'o @ 2012-07-31 22:34 UTC (permalink / raw)
  To: Eric Sandeen; +Cc: Nelson, John R, linux-ext4

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2012-07-31 22:34 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-07-31  2:17 Serious bug? Nelson, John R
2012-07-31  2:29 ` Eric Sandeen
2012-07-31  2:42 ` Theodore Ts'o
     [not found]   ` <0408C81F72528E40A0D3235A1F67FFC804A643@SN2PRD0202MB144.namprd02.prod.outlook.com>
     [not found]     ` <20120731032536.GE5027@thunk.org>
     [not found]       ` <0408C81F72528E40A0D3235A1F67FFC804A65F@SN2PRD0202MB144.namprd02.prod.outlook.com>
2012-07-31 21:38         ` Theodore Ts'o
2012-07-31 21:40           ` Eric Sandeen
2012-07-31 22:34             ` Theodore Ts'o

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).