public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
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

      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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox