On Feb 29, 2008 10:43 -0500, Theodore Ts'o wrote:
> * ad/nlinks-dir (Sat Feb 2 01:25:03 2008 -0700) 1 commit
> - e2fsprogs-nlinks.patch
>
> I'm really not sure about this change in e2fsck/pass4.c:
>
> - if (fix_problem(ctx, PR_4_BAD_REF_COUNT, &pctx)) {
> + /* i_link_count was previously exceeded, but no longer
> + * is, fix this but don't consider it an error */
> + if ((LINUX_S_ISDIR(inode->i_mode) && link_counted > 1 &&
> + (inode->i_flags & EXT2_INDEX_FL) &&
> + link_count == 1 && !(ctx->options & E2F_OPT_NO)) ||
> + (fix_problem(ctx, PR_4_BAD_REF_COUNT, &pctx))) {
> inode->i_links_count = link_counted;
> e2fsck_write_inode(ctx, i, inode, "pass4");
> }
>
> Why do we require EXT2_INDEX_FL to be set before deciding that
> it's OK if the i_link_count is 1 but we now have less than
> EXT2_LINK_MAX links?
The reason that INDEX_FL is important here is because only indexed
directories are allowed to exceed 65000 entries in the kernel. This is a
"save users from themselves" measure, because of the O(n^2) operations
needed to create/delete entries in unindexed directories. It also helps
detect the difference between corruption and expected behaviour.
> As a result of the "make check" failures which I mentioned at
> the beginning of this note, I noticed the following
> unfortunate problem in how errors are getting reported in
> e2fsck pass 5. As a sample:
>
> Block bitmap differences: +8195Group 3 block(s) in use but group is marked BLO
> CK_UNINIT
> Fix? yes
>
> This mangling is happening because error reporting for
> PR_5_INODE_UNINIT is getting intermingled with the
> PR_5_INODE_USED/PR_5_INODE_UNUSED reporting, which isn't a
> good idea. The comment around the code says:
>
> /*
> * We should never hit this, because it means that
> * inodes were marked in use that weren't noticed
> * in pass1 or pass 2. It is easier to fix the problem
> * than to kill e2fsck and leave the user stuck.
> */
>
> So I'm guessing there's something else wrong going on here....
Does this test case have both flexbg and uninit_groups? Alternately,
maybe some part of the e2fsck fixup code is allocating blocks in the
group, but doesn't know that the UNINIT flag needs to be cleared.
Instead of burning a lot of time on diagnosing this, I'd suggest to
try using the original uninit_groups patchset + Jose's patch on top of
that series to see if that works better?
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
