All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: Andreas Dilger <adilger@clusterfs.com>
Cc: Suzuki <suzuki@linux.vnet.ibm.com>,
	linux-ext4@vger.kernel.org, Amit K Arora <amitarora@in.ibm.com>,
	Mingming Cao <cmm@us.ibm.com>
Subject: Re: Ext3 onlie resize failure due to small journal size
Date: Thu, 12 Jul 2007 10:40:00 +0530	[thread overview]
Message-ID: <4695B7A8.1030008@linux.vnet.ibm.com> (raw)
In-Reply-To: <20070711173821.GA5495@schatzie.adilger.int>



Andreas Dilger wrote:
> On Jul 11, 2007  19:30 +0530, Suzuki wrote:
>> Trying to resize a mounted ext3 filesystem fails due to small journal size.
>>
>> Background :
>>
>> The filesystem was created with default values, except blocksize = 4K on 
>> a LV partition. Later we tried extended the partition to +16M and tried 
>> to resize the fs using resize2fs, while it was mounted.
>>
>> While adding the new blockgroup, inside setup_new_group_blocks() we hit 
>> the limit because we are requesting for a a credit value of 2 + 
>> sbi->s_itb_per_group which in the case of the file system below is 1026 
>> while the max_transaction credits possible is 1024 for the fs.
>>
>> journal->j_maxlen = inode->i_size / blocksize = 16M/4K = 4K
>>
>> journal->j_max_transaction_buffers = journal->j_maxlen / 4 = 1K
>>
>> journal->j_max_transaction_buffers = 1024.
>>
>> Is this a supported operation ? If yes, what could be the best way to 
>> fix it ?
>>
>> Resizing the journal is not supported at the moment :(.
> 
> You can't do a journal resize online, but you can wait until your next
> outage and resize the journal at that time.  Even a few extra blocks
> would be enough.  I guess this is a corner case that hasn't been hit
> before.  It might make sense to have the ext2fs_figure_journal_size()
> take this into account when making the filesystem?
> 
>

That't true. I was looking at it. I guess we should make sure we can
ask for a credit same as inode tables block per group + some extra.

Will try to see i can cook a patch.

-aneesh

  reply	other threads:[~2007-07-12  5:10 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-11 14:00 Ext3 onlie resize failure due to small journal size Suzuki
2007-07-11 17:38 ` Andreas Dilger
2007-07-12  5:10   ` Aneesh Kumar K.V [this message]
2007-07-11 19:47 ` Kalpak Shah

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=4695B7A8.1030008@linux.vnet.ibm.com \
    --to=aneesh.kumar@linux.vnet.ibm.com \
    --cc=adilger@clusterfs.com \
    --cc=amitarora@in.ibm.com \
    --cc=cmm@us.ibm.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=suzuki@linux.vnet.ibm.com \
    /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.