From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: Mingming Cao <cmm@us.ibm.com>
Cc: Eric Sandeen <sandeen@redhat.com>, ext4 <linux-ext4@vger.kernel.org>
Subject: Re: BUG with delayed allocation
Date: Thu, 20 Mar 2008 11:09:02 +0530 [thread overview]
Message-ID: <20080320053902.GD6967@skywalker> (raw)
In-Reply-To: <1205974018.3637.9.camel@localhost.localdomain>
On Wed, Mar 19, 2008 at 05:46:58PM -0700, Mingming Cao wrote:
> On Wed, 2008-03-19 at 14:22 +0530, Aneesh Kumar K.V wrote:
> > Hi,
> >
> > Eric actually observed it yesterday. I am able to reproduce it locally.
> > With delayed allocation we are observing wrong value of i_size.
> >
>
> The problem is current delalloc does not update on-disk i_size until
> writeout time, the in-core i_size is updated though.
>
ext4_da_writepages actually update the i_disksize during writeout time.
The writepage callback for delalloc was using ext4_writeback_writepage,
which didn't update the i_disksize. That is why some of the files have
correct size while some doesn't. I tested the below change and sent this
to list. But i appears vger dropped the mail to the list.
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 79930df..b74426d 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -1488,6 +1488,43 @@ out:
return ret;
}
+static int ext4_da_writepage(struct page *page,
+ struct writeback_control *wbc)
+{
+ struct inode *inode = page->mapping->host;
+ handle_t *handle = NULL;
+ int ret = 0;
+ int err;
+
+ if (ext4_journal_current_handle())
+ goto out_fail;
+
+ handle = ext4_journal_start(inode, ext4_writepage_trans_blocks(inode));
+ if (IS_ERR(handle)) {
+ ret = PTR_ERR(handle);
+ goto out_fail;
+ }
+
+ if (test_opt(inode->i_sb, NOBH) && ext4_should_writeback_data(inode))
+ ret = nobh_writepage(page, ext4_get_block, wbc);
+ else
+ ret = block_write_full_page(page, ext4_get_block, wbc);
+
+ if (!ret && inode->i_size > EXT4_I(inode)->i_disksize) {
+ EXT4_I(inode)->i_disksize = inode->i_size;
+ ext4_mark_inode_dirty(handle, inode);
+ }
+
+ err = ext4_journal_stop(handle);
+ if (!ret)
+ ret = err;
+ return ret;
+
+out_fail:
+ redirty_page_for_writepage(wbc, page);
+ unlock_page(page);
+ return ret;
+}
static int ext4_da_writepages(struct address_space *mapping,
struct writeback_control *wbc)
@@ -2015,7 +2052,7 @@ static const struct address_space_operations ext4_journalled_aops = {
static const struct address_space_operations ext4_da_aops = {
.readpage = ext4_readpage,
.readpages = ext4_readpages,
- .writepage = ext4_writeback_writepage,
+ .writepage = ext4_da_writepage,
.writepages = ext4_da_writepages,
.sync_page = block_sync_page,
.write_begin = ext4_da_write_begin,
> Could you try the following patch? It updates the i_disksize at the
> write_end time.
>
I will test the patch and update you. BTW shouldn't we update
i_disksize only after actual block got allocated ?
>
> Signed-off-by: Mingming Cao <cmm@us.ibm.com>
> ---
> fs/ext4/inode.c | 39 ++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 38 insertions(+), 1 deletion(-)
>
> Index: linux-2.6.25-rc5/fs/ext4/inode.c
> ===================================================================
> --- linux-2.6.25-rc5.orig/fs/ext4/inode.c 2008-03-19 17:32:44.000000000 -0700
> +++ linux-2.6.25-rc5/fs/ext4/inode.c 2008-03-19 17:43:19.000000000 -0700
> @@ -1355,6 +1355,43 @@ static int ext4_writeback_write_end(stru
> return ret ? ret : copied;
> }
>
> +static int ext4_da_write_end(struct file *file,
> + struct address_space *mapping,
> + loff_t pos, unsigned len, unsigned copied,
> + struct page *page, void *fsdata)
> +{
> + handle_t *handle;
> + struct inode *inode = file->f_mapping->host;
> + int needed_blocks = ext4_writepage_trans_blocks(inode);
> + int ret = 0, ret2;
> + loff_t new_i_size;
> +
> + handle = ext4_journal_start(inode, needed_blocks);
> + if (IS_ERR(handle)) {
> + unlock_page(page);
> + page_cache_release(page);
> + ret = PTR_ERR(handle);
> + return ret;
> + }
> +
> + new_i_size = pos + copied;
> + if (new_i_size > EXT4_I(inode)->i_disksize)
> + EXT4_I(inode)->i_disksize = new_i_size;
> +
> + copied = ext4_generic_write_end(file, mapping, pos, len, copied,
> + page, fsdata);
> + if (copied < 0)
> + ret = copied;
> +
> + ret2 = ext4_journal_stop(handle);
> + if (!ret)
> + ret = ret2;
> + unlock_page(page);
> + page_cache_release(page);
> +
> + return ret ? ret : copied;
> +}
> +
> static int ext4_journalled_write_end(struct file *file,
> struct address_space *mapping,
> loff_t pos, unsigned len, unsigned copied,
> @@ -2020,7 +2057,7 @@ static const struct address_space_operat
> .writepages = ext4_da_writepages,
> .sync_page = block_sync_page,
> .write_begin = ext4_da_write_begin,
> - .write_end = generic_write_end,
> + .write_end = ext4_da_write_end,
> .bmap = ext4_bmap,
> .invalidatepage = ext4_da_invalidatepage,
> .releasepage = ext4_releasepage,
>
>
-aneesh
next prev parent reply other threads:[~2008-03-20 5:40 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-19 8:52 BUG with delayed allocation Aneesh Kumar K.V
2008-03-19 14:42 ` Eric Sandeen
2008-03-19 18:32 ` Aneesh Kumar K.V
2008-03-20 4:21 ` Aneesh Kumar K.V
2008-03-20 0:46 ` Mingming Cao
2008-03-20 5:39 ` Aneesh Kumar K.V [this message]
2008-03-20 17:29 ` Mingming Cao
2008-03-20 17:56 ` Aneesh Kumar K.V
2008-03-20 23:55 ` Andreas Dilger
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=20080320053902.GD6967@skywalker \
--to=aneesh.kumar@linux.vnet.ibm.com \
--cc=cmm@us.ibm.com \
--cc=linux-ext4@vger.kernel.org \
--cc=sandeen@redhat.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.