<div>hi, all<br>I also hit ldiskfs problems.I have two osts report messages like this.<br>LDISKFS-fs: group 22879: 30128 blocks in bitmap, 29885 in gd<br>LDISKFS-fs: group 22810: 29150 blocks in bitmap, 29242 in gd<br>LDISKFS-fs: group 22846: 28278 blocks in bitmap, 28324 in gd<br>
...<br>Does it mean LDISKFS will corrupted at some time later?<br> <br>Also one ost  reported messages like "Remounting ... read-only", so some files cann't be write at that time.We have run e2fsck to fix it. But it reported again now.<br>
We have found that ldiskfs seems unstable since 1.6.(1.4  better than 1.6)<br>We have worryed about problem like filessystem corruption.Anyone can give some suggestion?<br> <br><br></div>
<div class="gmail_quote">2009/12/4 Craig Prescott <span dir="ltr"><<a href="mailto:prescott@hpc.ufl.edu">prescott@hpc.ufl.edu</a>></span><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div class="im">Craig Prescott wrote:<br>> Andreas Dilger wrote:<br>>> Hmm, the code shouldn't be checking the checksums if the uninit_bg<br>>> feature is not enabled.  I believe this was fixed in ext4 already:<br>
>><br>>> in ldiskfs_group_desc_csum_verify() change it to be:<br>>><br>>> int ldiskfs_group_desc_csum_verify(struct ext4_sb_info *sbi,<br>>>                                    __u32 block_group,<br>
>>                                    struct ext4_group_desc *gdp)<br>>> {<br>>>         if ((sbi->s_es->s_feature_ro_compat &<br>>>              cpu_to_le32(LDISKFS_FEATURE_RO_COMPAT_GDT_CSUM)) &&<br>
>>             (gdp->bg_checksum != ldiskfs_group_desc_csum(sbi,<br>>> block_group, gdp)))<br>>>                 return 0;<br>>>         return 1;<br>>> }<br>><br>> Ok, thanks.  I'll try that.<br>
><br></div><snip><br>
<div class="im">> Again, I really appreciate the help, and will let the list know how it<br>> goes.<br><br></div>Sadly, we didn't have any luck with this.  We had written off the OST in<br>our minds anyway, so to get any of the data back would have been a windfall.<br>
<br>Wouldn't mount as ldiskfs with the group descriptor checksum disabled:<br><br>Dec  3 10:58:05 tebow2 kernel: LDISKFS-fs error (device dm-7):<br>ldiskfs_check_descriptors: Block bitmap for group 10112 not in group (block<br>
484237063)!<br>Dec  3 10:58:05 tebow2 kernel: LDISKFS-fs: group descriptors corrupted!<br><br>Disabling that check and trying to mount yielded this one:<br><br>Dec  3 11:01:13 tebow2 kernel: LDISKFS-fs error (device dm-7):<br>
ldiskfs_check_descriptors: Inode bitmap for group 10112 not in group (block<br>14342712)!<br>Dec  3 11:01:13 tebow2 kernel: LDISKFS-fs: group descriptors corrupted!<br><br>Disabling that check yielded this one:<br><br>Dec  3 11:01:59 tebow2 kernel: LDISKFS-fs error (device dm-7):<br>
ldiskfs_check_descriptors: Inode table for group 10112 not in group (block<br>3538357782)!<br>Dec  3 11:01:59 tebow2 kernel: LDISKFS-fs: group descriptors corrupted!<br><br>All these messages were seen repeatedly in our fsck attempts.  If we had<br>
been able to get past this group, several thousand more would have followed.<br><br>Disabling the inode table present in group check:<br><br>Dec  3 11:02:35 tebow2 kernel: ldiskfs: No journal on filesystem on dm-7<br><br>
At that point we tried to rewrite superblocks with mkfs.lustre and<br>--mkfsoptions="-S", which panic'd the OSS.  At that point, we gave up.<br><br>Though it didn't work out this time, we'll be in a better position to be<br>
successful if this happens ever again.<br>
<div>
<div></div>
<div class="h5"><br>Thanks,<br>Craig Prescott<br>UF HPC Center<br>_______________________________________________<br>Lustre-discuss mailing list<br><a href="mailto:Lustre-discuss@lists.lustre.org">Lustre-discuss@lists.lustre.org</a><br>
<a href="http://lists.lustre.org/mailman/listinfo/lustre-discuss" target="_blank">http://lists.lustre.org/mailman/listinfo/lustre-discuss</a><br></div></div></blockquote></div><br>