Patchwork [10/12] ext4: fix the number of credits needed for ext4_unlink() and ext4_rmdir()

login
register
mail settings
Submitter Theodore Ts'o
Date Feb. 9, 2013, 9:53 p.m.
Message ID <1360446832-12724-11-git-send-email-tytso@mit.edu>
Download mbox | patch
Permalink /patch/219457/
State Accepted
Headers show

Comments

Theodore Ts'o - Feb. 9, 2013, 9:53 p.m.
The ext4_unlink() and ext4_rmdir() don't actually release the blocks
associated with the file/directory.  This gets done in a separate jbd2
handle called via ext4_evict_inode().  Thus, we don't need to reserve
lots of journal credits for the truncate.

Note that using too many journal credits is non-optimal because it can
leading to the journal transmit getting closed too early, before it is
strictly necessary.

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
---
 fs/ext4/ext4_jbd2.h | 6 ------
 fs/ext4/namei.c     | 4 ++--
 2 files changed, 2 insertions(+), 8 deletions(-)
Jan Kara - Feb. 11, 2013, 4:28 p.m.
On Sat 09-02-13 16:53:50, Ted Tso wrote:
> The ext4_unlink() and ext4_rmdir() don't actually release the blocks
> associated with the file/directory.  This gets done in a separate jbd2
> handle called via ext4_evict_inode().  Thus, we don't need to reserve
> lots of journal credits for the truncate.
> 
> Note that using too many journal credits is non-optimal because it can
> leading to the journal transmit getting closed too early, before it is
> strictly necessary.
  Nice spotting. The patch looks good. You can add:
Reviewed-by: Jan Kara <jack@suse.cz>

								Honza

> 
> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
> ---
>  fs/ext4/ext4_jbd2.h | 6 ------
>  fs/ext4/namei.c     | 4 ++--
>  2 files changed, 2 insertions(+), 8 deletions(-)
> 
> diff --git a/fs/ext4/ext4_jbd2.h b/fs/ext4/ext4_jbd2.h
> index 302814b..c1fc2dc 100644
> --- a/fs/ext4/ext4_jbd2.h
> +++ b/fs/ext4/ext4_jbd2.h
> @@ -59,12 +59,6 @@
>  #define EXT4_META_TRANS_BLOCKS(sb)	(EXT4_XATTR_TRANS_BLOCKS + \
>  					EXT4_MAXQUOTAS_TRANS_BLOCKS(sb))
>  
> -/* Delete operations potentially hit one directory's namespace plus an
> - * entire inode, plus arbitrary amounts of bitmap/indirection data.  Be
> - * generous.  We can grow the delete transaction later if necessary. */
> -
> -#define EXT4_DELETE_TRANS_BLOCKS(sb)	(2 * EXT4_DATA_TRANS_BLOCKS(sb) + 64)
> -
>  /* Define an arbitrary limit for the amount of data we will anticipate
>   * writing to any given transaction.  For unbounded transactions such as
>   * write(2) and truncate(2) we can write more than this, but we always
> diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
> index 36a4afd..5f3d2b5 100644
> --- a/fs/ext4/namei.c
> +++ b/fs/ext4/namei.c
> @@ -2748,7 +2748,7 @@ static int ext4_rmdir(struct inode *dir, struct dentry *dentry)
>  		goto end_rmdir;
>  
>  	handle = ext4_journal_start(dir, EXT4_HT_DIR,
> -				    EXT4_DELETE_TRANS_BLOCKS(dir->i_sb));
> +				    EXT4_DATA_TRANS_BLOCKS(dir->i_sb));
>  	if (IS_ERR(handle)) {
>  		retval = PTR_ERR(handle);
>  		handle = NULL;
> @@ -2811,7 +2811,7 @@ static int ext4_unlink(struct inode *dir, struct dentry *dentry)
>  		goto end_unlink;
>  
>  	handle = ext4_journal_start(dir, EXT4_HT_DIR,
> -				    EXT4_DELETE_TRANS_BLOCKS(dir->i_sb));
> +				    EXT4_DATA_TRANS_BLOCKS(dir->i_sb));
>  	if (IS_ERR(handle)) {
>  		retval = PTR_ERR(handle);
>  		handle = NULL;
> -- 
> 1.7.12.rc0.22.gcdd159b
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
Theodore Ts'o - Feb. 11, 2013, 6:30 p.m.
On Mon, Feb 11, 2013 at 05:28:30PM +0100, Jan Kara wrote:
> On Sat 09-02-13 16:53:50, Ted Tso wrote:
> > The ext4_unlink() and ext4_rmdir() don't actually release the blocks
> > associated with the file/directory.  This gets done in a separate jbd2
> > handle called via ext4_evict_inode().  Thus, we don't need to reserve
> > lots of journal credits for the truncate.
> > 
> > Note that using too many journal credits is non-optimal because it can
> > leading to the journal transmit getting closed too early, before it is
> > strictly necessary.
>   Nice spotting. The patch looks good. You can add:
> Reviewed-by: Jan Kara <jack@suse.cz>

The change in how ext4_unlink() works goes back years and years, so
this patch is applicable to ext3 as well.  I imagine a some of these
patches, such as the one where we now can start the handle in
ext4_new_inode(), or changing the order in which we call
grab_cache_page() and journal_start(), will probably be too
complicated for you to feel comfortable backporting them to ext3.
This one is really simple though, so maybe it's worth it.

The other ones you might want to consider is the patches do the
directory lookup before before start the journal, since they are
pretty easy to validate by inspection.

Cheers,

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jan Kara - Feb. 11, 2013, 7:30 p.m.
On Mon 11-02-13 13:30:36, Ted Tso wrote:
> On Mon, Feb 11, 2013 at 05:28:30PM +0100, Jan Kara wrote:
> > On Sat 09-02-13 16:53:50, Ted Tso wrote:
> > > The ext4_unlink() and ext4_rmdir() don't actually release the blocks
> > > associated with the file/directory.  This gets done in a separate jbd2
> > > handle called via ext4_evict_inode().  Thus, we don't need to reserve
> > > lots of journal credits for the truncate.
> > > 
> > > Note that using too many journal credits is non-optimal because it can
> > > leading to the journal transmit getting closed too early, before it is
> > > strictly necessary.
> >   Nice spotting. The patch looks good. You can add:
> > Reviewed-by: Jan Kara <jack@suse.cz>
> 
> The change in how ext4_unlink() works goes back years and years, so
> this patch is applicable to ext3 as well.  I imagine a some of these
> patches, such as the one where we now can start the handle in
> ext4_new_inode(), or changing the order in which we call
> grab_cache_page() and journal_start(), will probably be too
> complicated for you to feel comfortable backporting them to ext3.
> This one is really simple though, so maybe it's worth it.
> 
> The other ones you might want to consider is the patches do the
> directory lookup before before start the journal, since they are
> pretty easy to validate by inspection.
  Yeah, I will likely take the easy ones into ext3 but I definitely don't
plan to port the change in ext4_new_inode() into ext3.

								Honza

Patch

diff --git a/fs/ext4/ext4_jbd2.h b/fs/ext4/ext4_jbd2.h
index 302814b..c1fc2dc 100644
--- a/fs/ext4/ext4_jbd2.h
+++ b/fs/ext4/ext4_jbd2.h
@@ -59,12 +59,6 @@ 
 #define EXT4_META_TRANS_BLOCKS(sb)	(EXT4_XATTR_TRANS_BLOCKS + \
 					EXT4_MAXQUOTAS_TRANS_BLOCKS(sb))
 
-/* Delete operations potentially hit one directory's namespace plus an
- * entire inode, plus arbitrary amounts of bitmap/indirection data.  Be
- * generous.  We can grow the delete transaction later if necessary. */
-
-#define EXT4_DELETE_TRANS_BLOCKS(sb)	(2 * EXT4_DATA_TRANS_BLOCKS(sb) + 64)
-
 /* Define an arbitrary limit for the amount of data we will anticipate
  * writing to any given transaction.  For unbounded transactions such as
  * write(2) and truncate(2) we can write more than this, but we always
diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
index 36a4afd..5f3d2b5 100644
--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
@@ -2748,7 +2748,7 @@  static int ext4_rmdir(struct inode *dir, struct dentry *dentry)
 		goto end_rmdir;
 
 	handle = ext4_journal_start(dir, EXT4_HT_DIR,
-				    EXT4_DELETE_TRANS_BLOCKS(dir->i_sb));
+				    EXT4_DATA_TRANS_BLOCKS(dir->i_sb));
 	if (IS_ERR(handle)) {
 		retval = PTR_ERR(handle);
 		handle = NULL;
@@ -2811,7 +2811,7 @@  static int ext4_unlink(struct inode *dir, struct dentry *dentry)
 		goto end_unlink;
 
 	handle = ext4_journal_start(dir, EXT4_HT_DIR,
-				    EXT4_DELETE_TRANS_BLOCKS(dir->i_sb));
+				    EXT4_DATA_TRANS_BLOCKS(dir->i_sb));
 	if (IS_ERR(handle)) {
 		retval = PTR_ERR(handle);
 		handle = NULL;