linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@redhat.com>
To: Lukas Czerner <lczerner@redhat.com>, linux-ext4@vger.kernel.org
Subject: Re: [PATCH v2] e2fsprogs: Limit number of reserved gdt blocks on small fs
Date: Fri, 24 Apr 2015 16:51:44 -0500	[thread overview]
Message-ID: <553ABAF0.2020702@redhat.com> (raw)
In-Reply-To: <1427280382-31120-1-git-send-email-lczerner@redhat.com>

On 3/25/15 5:46 AM, Lukas Czerner wrote:
> Currently we're unable to online resize very small (smaller than 32 MB)
> file systems with 1k block size because there is not enough space in the
> journal to put all the reserved gdt blocks.

So, I'll get to the patch review if I need to, but this all seemed a little
odd; this is a regression, so do we really need to restrict things at mkfs
time?

On the userspace side, things were ok until:

9f6ba88 resize2fs: add support for new in-kernel online resize ioctl

and even with that, on the kernelspace side, things were ok until:

8f7d89f jbd2: transaction reservation support

I guess I'm trying to understand why that jbd2 commit regressed this.
I've not been paying enough attention to ext4 lately.  ;)

I mean, the threshold got chopped in half:

-       if (nblocks > journal->j_max_transaction_buffers) {
+       /*
+        * 1/2 of transaction can be reserved so we can practically handle
+        * only 1/2 of maximum transaction size per operation
+        */
+       if (WARN_ON(blocks > journal->j_max_transaction_buffers / 2)) {
                printk(KERN_ERR "JBD2: %s wants too many credits (%d > %d)\n",
-                      current->comm, nblocks,
-                      journal->j_max_transaction_buffers);
+                      current->comm, blocks,
+                      journal->j_max_transaction_buffers / 2);
                return -ENOSPC;
        }

so it's clear why the behavior changed, I guess, but it feels like I
must be missing something here.

The reproducer, for those playing along at home, is something like:

mkfs.ext4 /dev/sda 20M
mount /dev/sda /mnt/test
resize2fs /dev/sda 200M

-Eric



  reply	other threads:[~2015-04-24 21:51 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-25 10:46 [PATCH v2] e2fsprogs: Limit number of reserved gdt blocks on small fs Lukas Czerner
2015-04-24 21:51 ` Eric Sandeen [this message]
2015-04-25  4:25   ` Andreas Dilger
2015-04-27 16:14     ` Jan Kara
2015-04-27 16:23       ` Eric Sandeen
2015-04-28 12:21         ` Jan Kara
2015-04-28 12:24           ` Lukáš Czerner
2015-04-28 15:46             ` Eric Sandeen
2015-04-29 10:10               ` Jan Kara
2015-04-29 19:50                 ` Eric Sandeen

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=553ABAF0.2020702@redhat.com \
    --to=sandeen@redhat.com \
    --cc=lczerner@redhat.com \
    --cc=linux-ext4@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).