On Sep 15, 2006 20:11 +0200, Alexandre Ratchov wrote: > On Fri, Sep 15, 2006 at 10:57:43AM -0600, Andreas Dilger wrote: > > - the check for ee_start_hi and ei_leaf_hi fields (PR_1_EXTENT_HI) needs to > > be fixed (I don't see it changed here) so that it considers that an error > > only if INCOMPAT_64BIT flag is set and the filesystem is > 2^32 blocks. > > That is in e2fsck_ext_block_verify() > > - (FYI) In my definition of PR_1_EXTENT_HI I recently added the PR_PREEN_NOMSG > > flag because users were confused about the "High 16 bits of extent/index > > block set" message even though it is harmless for 32-bit filesystems. > > just to be sure to get it right: we allow 32bit file-systems to have extents > with _hi bits set, right? (and *_hi are ignored) Well, this is an undesirable side-effect of the old 32-bit extents code. e2fsck should just clear the _hi fields for 32-bit filesystems. For larger filesystems it should assume they are valid. That means that the PR_1_EXTENT_HI checks should just be skipped for > 32-bit filesystems. > so we can't simply assume that extents are always 48bit, in which case it > would be enough to just check that they are inside the block group (that > would detect extents with *_hi set as corrupt). For now I wouldn't change the ext4 code. The latest CFS e2fsprogs and kernel code clears the _hi fields correctly, and we can get our users to run an e2fsck before they ever start using ext4-based code (which likely won't be for a year or more) if they have a filesystem which still has _hi values set. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, 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
