Theodore Tso wrote: > On Mon, Feb 18, 2008 at 11:56:53AM -0600, Eric Sandeen wrote: >> So this trips up on things like sockets, fifos, and block & char nodes. >> >> Also this is unhappy: >> >>> @@ -137,7 +141,7 @@ int e2fsck_pass1_check_device_inode(ext2 >>> * If the index flag is set, then this is a bogus >>> * device/fifo/socket >>> */ >>> - if (inode->i_flags & EXT2_INDEX_FL) >>> + if (inode->i_flags & (EXT2_INDEX_FL | EXT4_EXTENTS_FL)) >>> return 0; >> Do we really care if these have the extents flag set? IOW should we >> make sure the kernel doesn't set the flag, or should we make e2fsck not >> care... > > <Sigh> > > I think we need to get kernel patches into mainline ASAP not to set > the EXTENTS_FL You mean on devices/fifos/sockets ? Ok. But today, with 2.6.25-rc1 and e2fsprogs-interim, long (non-fast) symlinks get clobbered by e2fsck, because: Pass 1: Checking inodes, blocks, and sizes Inode 12 has EXTENT_FL set, but is not in extents format Fix? yes Inode 12 has illegal block(s). Clear? yes Illegal block #0 (127754) in inode 12. CLEARED. Inode 12 is too big. Truncate? yes Block #1 (4) causes symlink to be too big. CLEARED. Block #4 (1) causes symlink to be too big. CLEARED. Block #5 (4772) causes symlink to be too big. CLEARED. Inode 12, i_blocks is 2, should be 0. Fix? yes Pass 2: Checking directory structure Symlink /longlink (inode #12) is invalid. Clear? yes Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information Block bitmap differences: -4772 Fix? yes Free blocks count wrong for group #0 (3420, counted=3421). Fix? yes Free blocks count wrong (26192, counted=26193). Fix? yes and *poof* it's gone. That one concerns me more... This *should* be in extents format, right, even though it's limited to one block... > and at least > for now, e2fsck needs to accept (and not complain or core dump) if > EXTENTS_FL is set for files where ext2fs_inode_has_valid_blocks() > returns false well, if any filetypes are not supposed to have the extents flag set, and they're zero-length, I'd say go ahead & clear it, and even complain if you like - it's the design intent after all - I wouldn't worry about the noise at this stage. FWIW, I haven't seen a core dump. :) -Eric - 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