linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Theodore Tso <tytso@mit.edu>
To: Gui Xiaohua <guixh@cn.fujitsu.com>
Cc: linux-ext4@vger.kernel.org
Subject: Re: [PATCH]:resize2fs:adjust the inode before inode_tables were covered
Date: Sat, 18 Apr 2009 23:21:27 -0400	[thread overview]
Message-ID: <20090419032127.GL19186@mit.edu> (raw)
In-Reply-To: <49B8C476.1010003@cn.fujitsu.com>

On Thu, Mar 12, 2009 at 04:14:46PM +0800, Gui Xiaohua wrote:
> Hi Ted
> There is a problem in your patch for resize2fs -M.
> You unmark the inode_table block in new fs,the blocks 
> which needed to be moved will cover the the inode_table
> blocks with its content.In inode_scan_and_fix func, we will
> scan the inode which in the old fs, but the inode table block
> had been coverd,then error occurs.
> I had fixed the problem through adjust the inode before blocks
> be moved.

Hi Gui,

Thanks for pointing out this problem.  It turns out there is an easier
solution, which involves reserving the blocks in the reserved_blocks
bitmap.  This prevents them from being reused, thus avoiding the
problem of old inode table getting overwritten before the inodes have
a chance to be moved.

Your solution has the advantage of not needing to reserve as much
"slop space", but the down side is that if the resize2fs is
interrupted after the inode table is overwritten but before the
directory blocks are updated to point at the new locations of the
inodes on disk, it would be much harder to recover the filesystem
after being interupted at such a bad point.

This problem could be solved by relocating the inodes first, then
updating the directory references, and then doing the block
relocations afterwards, but that would be a much larger change to
resize2fs.  The changes I elected to make, which I have just posted to
linux-ext4, and which you can see here:

    http://article.gmane.org/gmane.comp.file-systems.ext4/12762

... solve the problem in a much smaller set of changes.

    	      	      	   		    - Ted

  reply	other threads:[~2009-04-19  3:21 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-12  8:14 [PATCH]:resize2fs:adjust the inode before inode_tables were covered Gui Xiaohua
2009-04-19  3:21 ` Theodore Tso [this message]
  -- strict thread matches above, loose matches on Subject: below --
2009-02-13  9:47 Gui Xiaohua

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=20090419032127.GL19186@mit.edu \
    --to=tytso@mit.edu \
    --cc=guixh@cn.fujitsu.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).