Ext3 users - Dec 2001 - ext3_free_blocks

On a 2.4.15-pre5 system with a 3ware-Escalade-68000 IDE RAID (mode 1) we had the
follwing "dmesg" output today:

EXT3-fs error (device sd(8,38)): ext3_free_blocks: Freeing blocks in system
zones - Block = 16, count = 1
EXT3-fs error (device sd(8,38)): ext3_free_blocks: bit already cleared for block
1052672
EXT3-fs error (device sd(8,38)): ext3_free_blocks: Freeing blocks not in
datazone - block = 269488128, count = 1
EXT3-fs error (device sd(8,38)): ext3_free_blocks: Freeing blocks in system
zones - Block = 16, count = 1
EXT3-fs error (device sd(8,38)): ext3_free_blocks: bit already cleared for block
16

The filesystem this belongs to is /copymail:
LABEL=/copymail         /copymail       auto    nocheck,nosuid  1 2
mounted with the default journal mode.

The machine did NOT panic, halt or crash in a bizarre way.

Can this message occur when the controller remaps bad blocks on the disk?

-- 
Ralf Hildebrandt (Im Auftrag des Referat V A)   Ralf.Hildebrandt@charite.de
Charite Campus Virchow-Klinikum                 Tel.  +49 (0)30-450 570-155
Referat V A - Kommunikationsnetze -             Fax.  +49 (0)30-450 570-916

Hi,

On Mon, Dec 03, 2001 at 10:55:36AM +0100, Ralf Hildebrandt
wrote:
> On a 2.4.15-pre5 system with a 3ware-Escalade-68000 IDE RAID (mode 1) we
had the
> follwing "dmesg" output today:
> EXT3-fs error (device sd(8,38)): ext3_free_blocks: Freeing blocks in system
zones - Block = 16, count = 1
That's ext3 discovering that there is a file which thinks it owns
blocks in the reserved area of a block group.
> EXT3-fs error (device sd(8,38)): ext3_free_blocks: bit already cleared for
block 1052672
That's the fs detecting that there was a block in use in the
filesystem which was marked as free in the bitmap.  When ext3 came to
delete the block, it tried to mark it free in the bitmap and found it
already free.
> LABEL=/copymail         /copymail       auto    nocheck,nosuid  1 2
> mounted with the default journal mode.
> 
> The machine did NOT panic, halt or crash in a bizarre way.
ext3 tries very hard not to panic the kernel when it uncovers bad data
on disk.  It would be bad form to crash the system just because a user
inserted a corrupt zip disk, for example!
> Can this message occur when the controller remaps bad blocks on the disk?
The controller should never return bad data to the application in such
a case.  It _should_ just return an IO failure rather than returning
mush.  Unless there are other log messages in your syslog, that
doesn't seem to have happened here.

Either way, your disk is due a full forced fsck, I think!

Cheers,
 Stephen

> The controller should never return bad data to the application in such
> a case.  It _should_ just return an IO failure rather than returning
> mush.  Unless there are other log messages in your syslog, that
> doesn't seem to have happened here.
and what if the power gets lossed during the diskwrite of a block of data?
I mean; what if a sector in the journal gets only written half causing
corrupted data?