fsck: i_blocks is xxx should be yyy on ext3

fsck: i_blocks is xxx should be yyy on ext3

[Helge Hafting]

Today I rebooted into 2.6.16-rc2-mm1.  Fsck checked a "clean" ext3 fs,
because it was many mounts since the last time.

I have seen that many times, but this time I got a lot of
"i_blocks is xxx, should be yyy fix?"

In all cases, the blocks were fixed to a lower number.

I did a init 1, and checked the other filesystems.
It was the same everywhere, some i_blocks had do be fixed, and
the superblock was last updated in the future.

Is this normal somehow, or has something strange happened to ext3 lately?
I have experimented with the "barrier" option, but it gets disabled
because barrier based sync fails on the devices.  May this cause silent
errors? I thought I simply didn't get the advantages of barriers.
data=writeback made no difference from the default data=journal,
all filesystems had these wrong i_blocks.

Helge Hafting

Re: fsck: i_blocks is xxx should be yyy on ext3

[Andrew Morton]

Helge Hafting <helge.hafting@aitel.hist.no> wrote:
>
>  Today I rebooted into 2.6.16-rc2-mm1.  Fsck checked a "clean" ext3 fs,
>  because it was many mounts since the last time.
> 
>  I have seen that many times, but this time I got a lot of
>  "i_blocks is xxx, should be yyy fix?"
> 
>  In all cases, the blocks were fixed to a lower number.

Yes, thanks.  It's due to the ext3_getblocks() patches in -mm.  I can't
think of any actual harm which it'll cause.

To reproduce:

mkfs
mount
dbench 32
<wait 20 seconds>
killall dbench
umount
fsck

Re: fsck: i_blocks is xxx should be yyy on ext3

[Mingming Cao]

On Wed, 2006-02-08 at 22:53 -0800, Andrew Morton wrote:
> Helge Hafting <helge.hafting@aitel.hist.no> wrote:
> >
> >  Today I rebooted into 2.6.16-rc2-mm1.  Fsck checked a "clean" ext3 fs,
> >  because it was many mounts since the last time.
> > 
> >  I have seen that many times, but this time I got a lot of
> >  "i_blocks is xxx, should be yyy fix?"
> > 
> >  In all cases, the blocks were fixed to a lower number.
> 
> Yes, thanks.  It's due to the ext3_getblocks() patches in -mm.  I can't
> think of any actual harm which it'll cause.
> 
> To reproduce:
> 
> mkfs
> mount
> dbench 32
> <wait 20 seconds>
> killall dbench
> umount
> fsck
> -

Sorry about the late response.  I failed to reproduce the problem with
above instructions. I am running 2.6.16-rc2-mm1 kernel, played dbench
32 ,64 and 128, and tried both 8 cpu and 1 cpu, still no luck at last. I
am using e2fsck version 1.35 though. What versions you are using?


Thanks!

Mingming

Re: fsck: i_blocks is xxx should be yyy on ext3

[Andrew Morton]

Mingming Cao <cmm@us.ibm.com> wrote:
>
> On Wed, 2006-02-08 at 22:53 -0800, Andrew Morton wrote:
> > Helge Hafting <helge.hafting@aitel.hist.no> wrote:
> > >
> > >  Today I rebooted into 2.6.16-rc2-mm1.  Fsck checked a "clean" ext3 fs,
> > >  because it was many mounts since the last time.
> > > 
> > >  I have seen that many times, but this time I got a lot of
> > >  "i_blocks is xxx, should be yyy fix?"
> > > 
> > >  In all cases, the blocks were fixed to a lower number.
> > 
> > Yes, thanks.  It's due to the ext3_getblocks() patches in -mm.  I can't
> > think of any actual harm which it'll cause.
> > 
> > To reproduce:
> > 
> > mkfs
> > mount
> > dbench 32
> > <wait 20 seconds>
> > killall dbench
> > umount
> > fsck
> > -
> 
> Sorry about the late response.  I failed to reproduce the problem with
> above instructions. I am running 2.6.16-rc2-mm1 kernel, played dbench
> 32 ,64 and 128, and tried both 8 cpu and 1 cpu, still no luck at last.

It happens - I tried it just then.  It only failed one time in five
attempts, and that with just a single inode.


> I am using e2fsck version 1.35 though. What versions you are using?
> 

e2fsprogs-1.34-1

e2fsck -fn /dev/hda5

Re: fsck: i_blocks is xxx should be yyy on ext3

[Helge Hafting]

Mingming Cao wrote:

>On Wed, 2006-02-08 at 22:53 -0800, Andrew Morton wrote:
>  
>
>>Helge Hafting <helge.hafting@aitel.hist.no> wrote:
>>    
>>
>>> Today I rebooted into 2.6.16-rc2-mm1.  Fsck checked a "clean" ext3 fs,
>>> because it was many mounts since the last time.
>>>
>>> I have seen that many times, but this time I got a lot of
>>> "i_blocks is xxx, should be yyy fix?"
>>>
>>> In all cases, the blocks were fixed to a lower number.
>>>      
>>>
>>Yes, thanks.  It's due to the ext3_getblocks() patches in -mm.  I can't
>>think of any actual harm which it'll cause.
>>
>>To reproduce:
>>
>>mkfs
>>mount
>>dbench 32
>><wait 20 seconds>
>>killall dbench
>>umount
>>fsck
>>-
>>    
>>
>
>Sorry about the late response.  I failed to reproduce the problem with
>above instructions. I am running 2.6.16-rc2-mm1 kernel, played dbench
>32 ,64 and 128, and tried both 8 cpu and 1 cpu, still no luck at last. I
>am using e2fsck version 1.35 though. What versions you are using?
>  
>
single cpu, e2fsck 1.39-WIP (31-Dec-2005)
        Using EXT2FS Library version 1.39-WIP, 31-Dec-2005

I didn't use dbench, only normal use of the machine.

Helge Hafting

Re: fsck: i_blocks is xxx should be yyy on ext3

[Mingming Cao]

On Thu, 2006-02-16 at 08:47 +0100, Helge Hafting wrote:
> Mingming Cao wrote:
> 
> >On Wed, 2006-02-08 at 22:53 -0800, Andrew Morton wrote:
> >  
> >
> >>Helge Hafting <helge.hafting@aitel.hist.no> wrote:
> >>    
> >>
> >>> Today I rebooted into 2.6.16-rc2-mm1.  Fsck checked a "clean" ext3 fs,
> >>> because it was many mounts since the last time.
> >>>
> >>> I have seen that many times, but this time I got a lot of
> >>> "i_blocks is xxx, should be yyy fix?"
> >>>
> >>> In all cases, the blocks were fixed to a lower number.
> >>>      
> >>>
> >>Yes, thanks.  It's due to the ext3_getblocks() patches in -mm.  I can't
> >>think of any actual harm which it'll cause.
> >>
> >>To reproduce:
> >>
> >>mkfs
> >>mount
> >>dbench 32
> >><wait 20 seconds>
> >>killall dbench
> >>umount
> >>fsck
> >>-
> >>    
> >>
> >
> >Sorry about the late response.  I failed to reproduce the problem with
> >above instructions. I am running 2.6.16-rc2-mm1 kernel, played dbench
> >32 ,64 and 128, and tried both 8 cpu and 1 cpu, still no luck at last. I
> >am using e2fsck version 1.35 though. What versions you are using?
> >  
> >
> single cpu, e2fsck 1.39-WIP (31-Dec-2005)
>         Using EXT2FS Library version 1.39-WIP, 31-Dec-2005
> 
> I didn't use dbench, only normal use of the machine.
> 
> Helge Hafting
> 
> 

I was able to constantly reproduce this problem on another machine with
1 cpu, and find the bug.  

In the ext3_new_blocks() code, if the # of allocated blocks (num) is
less than the requested # of blocks to allocate (*count), we will need
to free some quota via DQUOT_FREE_BLOCK(), which will eventually adjust
i_blocks value properly. the delta value *count-num is wrong, as we re-
set the *count too early.


The patch seems fixed the bug on my machine, could you please give it a
try?

Thanks.


 linux-2.6.15-cmm/fs/ext3/balloc.c |    2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

diff -puN fs/ext3/balloc.c~ext3-getblocks-i_blocks-fix fs/ext3/balloc.c
--- linux-2.6.15/fs/ext3/balloc.c~ext3-getblocks-i_blocks-fix
2006-02-16 10:19:23.000000000 -0800
+++ linux-2.6.15-cmm/fs/ext3/balloc.c   2006-02-16 10:19:49.000000000
-0800
@@ -1441,8 +1441,8 @@ allocated:

        *errp = 0;
        brelse(bitmap_bh);
-       *count = num;
        DQUOT_FREE_BLOCK(inode, *count-num);
+       *count = num;
        return ret_block;

 io_error: