All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@redhat.com>
To: "Theodore Ts'o" <tytso@mit.edu>, Andreas Dilger <adilger@dilger.ca>
Cc: ext4 development <linux-ext4@vger.kernel.org>
Subject: Re: Journal under-reservation bug on first >2G file
Date: Wed, 01 Oct 2014 09:43:32 -0500	[thread overview]
Message-ID: <542C1314.3030603@redhat.com> (raw)
In-Reply-To: <20141001115320.GA2903@thunk.org>

On 10/1/14 6:53 AM, Theodore Ts'o wrote:
> On Tue, Sep 30, 2014 at 03:36:17PM -0600, Andreas Dilger wrote:
>>>
>>>  1.5a) Always set the large_file feature with a fresh mkfs, insteadl
>>>        of relying on the accident of the resize inode being > 2G!
>>
>> I think that 1.5a is definitely the way to go for new mke2fs, I'm a
>> bit surprised that we didn't do this for "-t ext4" a long time ago
>> given that we've enabled lots of other features automatically.
> 
> Yes, I agree that would be a good thing to do.  I'll make the change
> to mke2fs.conf.
> 
>> There shouldn't be any problem to do this retroactively in e2fsck
>> and potentially at mount time for filesystems that already have some
>> features enabled that are post-large_file (e.g. extents, flex_bg, etc.)
>> This definitely would not impose any compatibility issues, because any
>> kernel that supports those features already understands large_file.
> 
> That sounds like a plan.  If we only enable it automatically at mount
> time (iff we mounted the file system read/write) if any of the ext3 or
> ext4 specific features are enabled, that should be completely safe.

Ok, so do that, and don't bump the reservations? I suppose
the size test & superblock write can be removed, then...

This does bug me a little; at one point we were very carefully not
enabling any new features by mounting with a new kernel; that was
specific to mounting-ext2-with-ext4 etc, but it still feels slightly
inconsistent.  Although I guess we enable it today by mounting-and-
writing-a-big-enough-file.

Something like this should fix it too, though, with less unexpected
behind-your-back behavior:

diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 3aa26e9..2f94cd6 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -2563,9 +2563,15 @@ retry_grab:
         * if there is delayed block allocation. But we still need
         * to journalling the i_disksize update if writes to the end
         * of file which has an already mapped buffer.
+        * If this write might need to update the superblock due to the
+        * filesize adding a new superblock feature flag, add that too.
         */
 retry_journal:
-       handle = ext4_journal_start(inode, EXT4_HT_WRITE_PAGE, 1);
+       handle = ext4_journal_start(inode, EXT4_HT_WRITE_PAGE,
+                                   EXT4_HAS_RO_COMPAT_FEATURE(inode->i_sb,
+                                       EXT4_FEATURE_RO_COMPAT_LARGE_FILE) ?
+                                   1 : 2);
+
        if (IS_ERR(handle)) {
                page_cache_release(page);
                return PTR_ERR(handle);


-ERic

  reply	other threads:[~2014-10-01 14:43 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-30 21:10 Journal under-reservation bug on first >2G file Eric Sandeen
2014-09-30 21:22 ` Eric Sandeen
2014-09-30 21:36   ` Andreas Dilger
2014-09-30 22:10     ` Darrick J. Wong
2014-10-01 11:53     ` Theodore Ts'o
2014-10-01 14:43       ` Eric Sandeen [this message]
2014-10-01 19:59         ` Theodore Ts'o
2014-10-01 20:37           ` Eric Sandeen
2014-10-01 22:43             ` Theodore Ts'o
2014-10-02  5:49               ` Eric Sandeen
2014-10-02 11:26                 ` Jan Kara

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=542C1314.3030603@redhat.com \
    --to=sandeen@redhat.com \
    --cc=adilger@dilger.ca \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.