Re: ext3 filesystem corruption on md RAID1 device

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



  Hi,

On Sun 23-05-10 05:46:29, Buehl, Reiner wrote:
> Hi Ted,
> 
> please find attached the output of two fsck.ext3 -fy /dev/md1 runs
> conducted directly after each other. The ext3 fs error message in dmesg
> was:
  I took a look at the fsck logs. So there are inodes 17269110-17269115
(from group 2108 if my counting is correct) that have problems. 17269110 is
the corrupted directory, 17269111 is an unconnected directory (was subdir of
17269110), 17269112-17269115 share blocks with some other inodes.
  Interestingly enough, these other inodes are all in group 2120 and also
the blocks that are shared are in group 2120.
  Multiply claimed blocks in this amount are usually caused by a corrupted
block bitmap. In your case, it seems as if bitmap for group 2120 was not
written (or was zeroed?) and thus later some inodes reused the space. This
kind of corruption is usually caused by HW - flaky memory or disk
controller (I wouldn't suspect disks in your case since the problem seems to
consistently happen on both the original disk and the mirror). Do you have
any chance of trying a different HW?

								Honza
-- 
Jan Kara <jack@xxxxxxx>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux