e2fsprogs: add large_file to base mkfs features

large_file (> 2G) support has been around since at least kernel 2.4;
mkfs of any sufficiently large filesystem sets it "accidentally"
when the resize inode exceeds 2G.  This leaves very small
filesystems lacking the feature, which potentially changes
their behavior & codepaths the first time a > 2G file gets
written.

There's really no reason to be making fresh filesystems which
strive to keep compatibility with 10 year old kernels; just
enable large_file at mkfs time.  This is particularly obvious
for ext4 fielsystems, which set huge_file by default, but not
necessarily large_file.

If old-kernel compatibility is desired, mke2fs.conf can be
modified locally to remove the feature.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
---


--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Sep 30, 2014, at 9:26 PM, Eric Sandeen <sandeen@redhat.com> wrote:

> large_file (> 2G) support has been around since at least kernel 2.4;
> mkfs of any sufficiently large filesystem sets it "accidentally"
> when the resize inode exceeds 2G.  This leaves very small
> filesystems lacking the feature, which potentially changes
> their behavior & codepaths the first time a > 2G file gets
> written.
> 
> There's really no reason to be making fresh filesystems which
> strive to keep compatibility with 10 year old kernels; just
> enable large_file at mkfs time.  This is particularly obvious
> for ext4 fielsystems, which set huge_file by default, but not
> necessarily large_file.
> 
> If old-kernel compatibility is desired, mke2fs.conf can be
> modified locally to remove the feature.
> 
> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>

Doing a bit of spelunking now that I have a chance, I see:

    commit 77175ca20cbfd8d8f3473a060bdbcb7f18505d1f
    Author: Theodore Ts'o <tytso@mit.edu>
    Date:   Wed Feb 27 00:00:30 2008 -0500

    e2fsck: Don't clear the LARGE_FILES feature flag
    
    Stop clearing the EXT2_FEATURE_RO_COMPAT_LARGE_FILE flag automatically
    if there are no large files in the filesystem.  It's been almost a
    decade since there have been kernels that don't support this flag, and
    e2fsck clears it quietly without telling the user why the filesystem
    has been changed.
    
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>

So that means kernels have been supporting large_file since about 1998,
about 16 years already...  The first e2fsprogs git mention is also 1998,
and I found the original kernel patch:

    http://lkml.org/lkml/1998/3/12/99
    
    Date	Thu, 12 Mar 1998 23:12:53 -0500
    Subject	Ext2 patches for Linux 2.1
    From	tytso@mit.edu

    Hi Linus, 

    Could you please install this patch set into the 2.1 tree?  It
    includes previous patches submitted by Stephen and Jakub (with some
    fixes) and my own patches and improvements.  None of these are really
    major changes; most of them are changes to provide better a forward
    migration path past Linux 2.2 for future ext2fs features.
    :
    :
    * Added Jakub Jelinek's support for large files on 64-bit
	platforms.  On a 64-bit platform, the first time you
	expand a file past the 32-bit boundary, the 
	EXT2_FEATURE_RO_COMPAT_LARGE_FILE is turned on.
	2.0 machines will be able to mount such filesystems
	read-only.  2.2 kernels on 32-bit platforms will be
	able such filesystems read-write, but they will only
	be able to see the first 2**32 bytes of the file, and
	any attempt to open a large file for read/write access
	will cause an EBIGF error.

This was also bundled with the INCOMPAT_FILETYPE feature, so I see
virtually no risk to enable this feature via e2fsck for any ext3 or
ext4 filesystems (INCOMPAT_FILETYPE was added before INCOMPAT_RECOVER
for ext3).

Cheers, Andreas

> ---
> 
> diff --git a/misc/mke2fs.c b/misc/mke2fs.c
> index 2bc435b..2a16c59 100644
> --- a/misc/mke2fs.c
> +++ b/misc/mke2fs.c
> @@ -1927,7 +1927,7 @@ profile_error:
> 	tmp = NULL;
> 	if (fs_param.s_rev_level != EXT2_GOOD_OLD_REV) {
> 		tmp = get_string_from_profile(fs_types, "base_features",
> -		      "sparse_super,filetype,resize_inode,dir_index");
> +		      "sparse_super,large_file,filetype,resize_inode,dir_index");
> 		edit_feature(tmp, &fs_param.s_feature_compat);
> 		free(tmp);
> 
> diff --git a/misc/mke2fs.conf.in b/misc/mke2fs.conf.in
> index 4c5dba7..106ee80 100644
> --- a/misc/mke2fs.conf.in
> +++ b/misc/mke2fs.conf.in
> @@ -1,5 +1,5 @@
> [defaults]
> -	base_features = sparse_super,filetype,resize_inode,dir_index,ext_attr
> +	base_features = sparse_super,large_file,filetype,resize_inode,dir_index,ext_attr
> 	default_mntopts = acl,user_xattr
> 	enable_periodic_fsck = 0
> 	blocksize = 4096
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


Cheers, Andreas

On Tue, Sep 30, 2014 at 10:26:03PM -0500, Eric Sandeen wrote:
> large_file (> 2G) support has been around since at least kernel 2.4;
> mkfs of any sufficiently large filesystem sets it "accidentally"
> when the resize inode exceeds 2G.  This leaves very small
> filesystems lacking the feature, which potentially changes
> their behavior & codepaths the first time a > 2G file gets
> written.
> 
> There's really no reason to be making fresh filesystems which
> strive to keep compatibility with 10 year old kernels; just
> enable large_file at mkfs time.  This is particularly obvious
> for ext4 fielsystems, which set huge_file by default, but not
> necessarily large_file.
> 
> If old-kernel compatibility is desired, mke2fs.conf can be
> modified locally to remove the feature.
> 
> Signed-off-by: Eric Sandeen <sandeen@redhat.com>

Applied, thanks.

					- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html