From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: Eric Sandeen <sandeen@redhat.com>
Cc: cmm@us.ibm.com, tytso@mit.edu, linux-ext4@vger.kernel.org
Subject: Re: [RFC PATCH] ext4: Fix fallocate to update the file size in each transaction.
Date: Sat, 8 Mar 2008 21:41:27 +0530 [thread overview]
Message-ID: <20080308161127.GA6992@skywalker> (raw)
In-Reply-To: <47D16302.9090506@redhat.com>
On Fri, Mar 07, 2008 at 09:45:06AM -0600, Eric Sandeen wrote:
> Aneesh Kumar K.V wrote:
> > ext4_fallocate need to update file size in each transaction. Otherwise
> > ife we crash the file size won't be updated. We were also not marking
> > the inode dirty after updating file size before.
>
> This led to losing the size update when unmounted...
>
> > Also when we try to
> > retry allocation due to ENOSPC make sure we reset the variable ret so
> > that we actually do a retry.
>
> That's a few alsos. Should this be more than one patch when committed?
>
> -Eric
>
> > Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> > ---
> > fs/ext4/extents.c | 78 +++++++++++++++++++++--------------------------------
> > 1 files changed, 31 insertions(+), 47 deletions(-)
> >
> > diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
> > index dcdf92a..09dd3c5 100644
> > --- a/fs/ext4/extents.c
> > +++ b/fs/ext4/extents.c
> > @@ -2783,6 +2783,26 @@ int ext4_ext_writepage_trans_blocks(struct inode *inode, int num)
> > return needed;
> > }
> >
> > +static void ext4_falloc_update_inode(struct inode *inode,
> > + int mode, loff_t new_size)
> > +{
> > + struct timespec now;
> > +
> > + now = current_fs_time(inode->i_sb);
> > + if (!timespec_equal(&inode->i_ctime, &now))
> > + inode->i_ctime = now;
>
> This used to depend on blocks actually being allocated; it looks like it
> doesn't anymore?
I am still not clear about the requirement here. The earlier code
check for greater than current file size, which was confusing because we
could very well convert a hole to a prealloc area. How about updating
i_ctime if the buffer head is new ?.
>
> > + /*
> > + * Update only when preallocation was requested beyond
> > + * the file size.
> > + */
> > + if (!(mode & FALLOC_FL_KEEP_SIZE) &&
> > break;
.....
> > }
> > - if (ret > 0) {
> > - /* check wrap through sign-bit/zero here */
> > - if ((block + ret) < 0 || (block + ret) < block) {
> > - ret = -EIO;
> > - ext4_mark_inode_dirty(handle, inode);
> > - ret2 = ext4_journal_stop(handle);
> > - break;
> > - }
> > - if (buffer_new(&map_bh) && ((block + ret) >
> > - (EXT4_BLOCK_ALIGN(i_size_read(inode), blkbits)
> > - >> blkbits)))
> > - nblocks = nblocks + ret;
> > - }
> > + if ((block + ret) >= (EXT4_BLOCK_ALIGN(offset + len,
> > + blkbits) >> blkbits))
> > + new_size = offset + len;
> > + else
> > + new_size = (block + ret) << blkbits;
>
> Since we called ext4_get_blocks_wrap with max_blocks, will we really end
> up with more blocks allocated than we asked for? And do we no longer
> need the wrap checks? (I'd expect that to be tested higher up with the
> original offset+len requested, no?)
ext4_get_blocks_wrap had confusing returns. Mingming actually fixed it
in the previous patch. We can actually return more bytes than requested
if we are calling ext4_get_blocks_wrap in read mode for an falloc area.
Well that is not really the case here. But having in >= is ok.
The wrap check there was not needed. The needed wrap check is to make sure
whether we are crossing the allowed max file size. That is done in
sys_fallocate.
>
> > - /* Update ctime if new blocks get allocated */
> > - if (nblocks) {
> > - struct timespec now;
> > -
> > - now = current_fs_time(inode->i_sb);
...
-aneesh
prev parent reply other threads:[~2008-03-08 16:12 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-07 10:53 [RFC PATCH] ext4: Fix fallocate to update the file size in each transaction Aneesh Kumar K.V
2008-03-07 11:30 ` Mingming Cao
2008-03-07 11:44 ` Aneesh Kumar K.V
2008-03-07 16:03 ` Dave Kleikamp
2008-03-07 17:59 ` Mingming Cao
2008-03-08 16:12 ` Aneesh Kumar K.V
2008-03-07 15:45 ` Eric Sandeen
2008-03-07 15:57 ` Eric Sandeen
2008-03-08 16:11 ` Aneesh Kumar K.V [this message]
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=20080308161127.GA6992@skywalker \
--to=aneesh.kumar@linux.vnet.ibm.com \
--cc=cmm@us.ibm.com \
--cc=linux-ext4@vger.kernel.org \
--cc=sandeen@redhat.com \
--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.