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
Helge Hafting <[email protected]> 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
On Wed, 2006-02-08 at 22:53 -0800, Andrew Morton wrote:
> Helge Hafting <[email protected]> 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
Mingming Cao <[email protected]> wrote:
>
> On Wed, 2006-02-08 at 22:53 -0800, Andrew Morton wrote:
> > Helge Hafting <[email protected]> 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
Mingming Cao wrote:
>On Wed, 2006-02-08 at 22:53 -0800, Andrew Morton wrote:
>
>
>>Helge Hafting <[email protected]> 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
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 <[email protected]> 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: