linux-ext4 - Re: [PATCH] allow tune2fs to set/clear resize

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 6 Nov 2007 09:12:55 +0800
From:	Andreas Dilger <adilger@....com>
To:	Eric Sandeen <sandeen@...hat.com>
Cc:	ext4 development <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH] allow tune2fs to set/clear resize_inode

On Nov 05, 2007  14:45 -0600, Eric Sandeen wrote:
> (this patch has been carried in Red Hat / Fedora rpms for a while, not 
> sure why it never got sent upstream... clearing this allows for mounting 
> filesystems with a resize_inode on older systems)
>
> Allow tune2fs to set & clear resize_inode; requires fsck afterwards.

Two things that are a bit confusing:
- since RESIZE_INODE is a COMPAT feature, I don't see how this affects
  mounting the filesystem on older systems?  Is there a bug somewhere?
- why not use something like remove_journal_inode() (or create a new
  helper function like ext2fs_unlink(), and move the kill_file_by_inode()
  and release_blocks_proc() into lib/ext2fs as ext2fs_delete_inode())
  to avoid the need for an e2fsck?

>  	if ((sparse != old_sparse) ||
> -	    (filetype != old_filetype)) {
> +	    (filetype != old_filetype) ||
> +	    (resize_inode != old_resize_inode)) {
>  		sb->s_state &= ~EXT2_VALID_FS;
>  		printf("\n%s\n", _(please_fsck));
>  	}

I don't know that it is so easy to enable RESIZE_INODE on an existing
filesystem as just setting the feature flag and running e2fsck?  The
reserved group descriptor blocks will potentially conflict with the
bitmaps and inode tables.

What is needed is an ext2prepare-like step that involves resize2fs code
to move the file/dir blocks and then the move inode table, as if the
filesystem were going to be resized to the new maximum resize limit,
and then create the resize inode but do not actually add new blocks/groups
at the end of the filesystem.

Cheers, Andreas
--
Andreas Dilger
Sr. Software 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html