Ext3 users - Oct 2008 - Block bitmap differences

Hi,

a few weeks ago, an unhealthy combination of firmware in an Adaptec Raid 
controller and Seagate disks damaged my Raid6 filesystem. A bunch of 
files were damaged or lost at that time after the firmaware was updated 
and I had run e2fsck. Luckily, I was able to restore everything from a 
backup. A subsequent check with e2fsck reported no errors.

Yesterday, I ran e2fsck -n again, to see if the system is still OK. It 
isn't and I have no idea how to interpret the messages (see attachment).

What is the meaning and severity of

- Block bitmap differences?
- Free blocks count wrong for group?


Thanks and regards.

Roland


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: e2fsck-n-2008-10-22
URL:
<http://listman.redhat.com/archives/ext3-users/attachments/20081023/d012f39c/attachment.ksh>

On Thu, Oct 23, 2008 at 10:00:44AM +0200, Roland Bock
wrote:
> Hi,
>
> a few weeks ago, an unhealthy combination of firmware in an Adaptec Raid  
> controller and Seagate disks damaged my Raid6 filesystem. A bunch of  
> files were damaged or lost at that time after the firmaware was updated  
> and I had run e2fsck. Luckily, I was able to restore everything from a  
> backup. A subsequent check with e2fsck reported no errors.
>
> Yesterday, I ran e2fsck -n again, to see if the system is still OK. It  
> isn't and I have no idea how to interpret the messages (see
attachment).
You ran the e2fsck while the filesystem is mounted.  So the output
reported is not trustworthy, and block allocation bitmap differences
and free block/inode accounting information being wrong is normal when
running e2fsck -n on a mounted filesystem.  

This message, however, is cause for concern:
> /dev/sdb1 contains a file system with errors, check forced.
This means the filesystem noticed some discrepancy (for example, when
freeing a block, it noticed that the block bitmap already showed the
block as being not in use, which should never happen and indicates
filesystem corruption).

I would recommend that you schedule downtime so you can run e2fsck on
the filesystem while it is unmounted.  Given the errors that you saw
when running e2fsck while it was mounted, it's unlikely that you will
see anything serious, but it is still something that you should do.

Regards,

							- Ted