* [PATCH] ext4: optimize extent selection for block removal in case of hole punch @ 2013-05-24 14:39 ashishsangwan2 2013-06-18 15:40 ` Theodore Ts'o 0 siblings, 1 reply; 6+ messages in thread From: ashishsangwan2 @ 2013-05-24 14:39 UTC (permalink / raw) To: tytso, adilger; +Cc: linux-ext4, Ashish Sangwan, Namjae Jeon From: Ashish Sangwan <a.sangwan@samsung.com> Both hole punch and truncate use ext4_ext_rm_leaf for removing blocks. Currently we choose the last extent as the starting point for removing blocks: ex = EXT_LAST_EXTENT(eh); This is OK for truncate but for hole punch we can optimize the extent selection as the path is already initialized. We could use this information to select proper starting extent. The code change in this patch will not affect truncate as for truncate path[depth].p_ext will always be NULL. Signed-off-by: Ashish Sangwan <a.sangwan@samsung.com> Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com> --- fs/ext4/extents.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index 3676dae..7c1a5d3 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -2490,7 +2490,9 @@ ext4_ext_rm_leaf(handle_t *handle, struct inode *inode, return -EIO; } /* find where to start removing */ - ex = EXT_LAST_EXTENT(eh); + ex = path[depth].p_ext; + if (!ex) + ex = EXT_LAST_EXTENT(eh); ex_ee_block = le32_to_cpu(ex->ee_block); ex_ee_len = ext4_ext_get_actual_len(ex); -- 1.7.2.3 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] ext4: optimize extent selection for block removal in case of hole punch 2013-05-24 14:39 [PATCH] ext4: optimize extent selection for block removal in case of hole punch ashishsangwan2 @ 2013-06-18 15:40 ` Theodore Ts'o 2013-06-19 13:45 ` Ashish Sangwan 0 siblings, 1 reply; 6+ messages in thread From: Theodore Ts'o @ 2013-06-18 15:40 UTC (permalink / raw) To: ashishsangwan2; +Cc: adilger, linux-ext4, Ashish Sangwan, Namjae Jeon On Fri, May 24, 2013 at 08:09:17PM +0530, ashishsangwan2@gmail.com wrote: > From: Ashish Sangwan <a.sangwan@samsung.com> > > Both hole punch and truncate use ext4_ext_rm_leaf for removing > blocks. Currently we choose the last extent as the starting > point for removing blocks: ex = EXT_LAST_EXTENT(eh); > This is OK for truncate but for hole punch we can optimize the > extent selection as the path is already initialized. > We could use this information to select proper starting extent. > The code change in this patch will not affect truncate as for > truncate path[depth].p_ext will always be NULL. > > Signed-off-by: Ashish Sangwan <a.sangwan@samsung.com> > Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com> Applied, thanks. - Ted ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] ext4: optimize extent selection for block removal in case of hole punch 2013-06-18 15:40 ` Theodore Ts'o @ 2013-06-19 13:45 ` Ashish Sangwan 2013-06-19 14:06 ` Theodore Ts'o 0 siblings, 1 reply; 6+ messages in thread From: Ashish Sangwan @ 2013-06-19 13:45 UTC (permalink / raw) To: Theodore Ts'o; +Cc: adilger, ext4 development, Ashish Sangwan, Namjae Jeon On Tue, Jun 18, 2013 at 9:10 PM, Theodore Ts'o <tytso@mit.edu> wrote: > On Fri, May 24, 2013 at 08:09:17PM +0530, ashishsangwan2@gmail.com wrote: >> From: Ashish Sangwan <a.sangwan@samsung.com> >> >> Both hole punch and truncate use ext4_ext_rm_leaf for removing >> blocks. Currently we choose the last extent as the starting >> point for removing blocks: ex = EXT_LAST_EXTENT(eh); >> This is OK for truncate but for hole punch we can optimize the >> extent selection as the path is already initialized. >> We could use this information to select proper starting extent. >> The code change in this patch will not affect truncate as for >> truncate path[depth].p_ext will always be NULL. >> >> Signed-off-by: Ashish Sangwan <a.sangwan@samsung.com> >> Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com> > > Applied, thanks. Hi Ted, Sorry I cannot see the patch changes in ext4 dev branch. Regards, Ashish > > - Ted ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] ext4: optimize extent selection for block removal in case of hole punch 2013-06-19 13:45 ` Ashish Sangwan @ 2013-06-19 14:06 ` Theodore Ts'o 2013-06-19 15:44 ` Ashish Sangwan 0 siblings, 1 reply; 6+ messages in thread From: Theodore Ts'o @ 2013-06-19 14:06 UTC (permalink / raw) To: Ashish Sangwan; +Cc: adilger, ext4 development, Ashish Sangwan, Namjae Jeon On Wed, Jun 19, 2013 at 07:15:35PM +0530, Ashish Sangwan wrote: > On Tue, Jun 18, 2013 at 9:10 PM, Theodore Ts'o <tytso@mit.edu> wrote: > > On Fri, May 24, 2013 at 08:09:17PM +0530, ashishsangwan2@gmail.com wrote: > >> From: Ashish Sangwan <a.sangwan@samsung.com> > >> > >> Both hole punch and truncate use ext4_ext_rm_leaf for removing > >> blocks. Currently we choose the last extent as the starting > >> point for removing blocks: ex = EXT_LAST_EXTENT(eh); > >> This is OK for truncate but for hole punch we can optimize the > >> extent selection as the path is already initialized. > >> We could use this information to select proper starting extent. > >> The code change in this patch will not affect truncate as for > >> truncate path[depth].p_ext will always be NULL. > >> > >> Signed-off-by: Ashish Sangwan <a.sangwan@samsung.com> > >> Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com> > > > > Applied, thanks. > > Sorry I cannot see the patch changes in ext4 dev branch. Sorry, I dropped this patch from the dev branch last night, but I didn't want to send e-mail about it until I had completed enough testing to be sure. It appears that this patch is causing a regression; xfstests generic/269 and generic/279 to fail in the nojournal configuration. The tests are ones which have multiple fsstress threads racing with dd/ENOSPC hitters, with (#270) and without (#269) quota enabled. It's not at all obvious to me why your particular change would make a difference here, and it may simply be that your optimization is exposing a timing change and is not the root cause of the failure, but I'm going to move this to the unstable portion of the patch series until we do further investigation. If you could take a look at this, I would appreciate it, but as I said, this may very well turn out not be the fault of your patch. Regards, - Ted ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] ext4: optimize extent selection for block removal in case of hole punch 2013-06-19 14:06 ` Theodore Ts'o @ 2013-06-19 15:44 ` Ashish Sangwan 2013-06-23 18:43 ` Theodore Ts'o 0 siblings, 1 reply; 6+ messages in thread From: Ashish Sangwan @ 2013-06-19 15:44 UTC (permalink / raw) To: Theodore Ts'o; +Cc: adilger, ext4 development, Ashish Sangwan, Namjae Jeon On Wed, Jun 19, 2013 at 7:36 PM, Theodore Ts'o <tytso@mit.edu> wrote: > On Wed, Jun 19, 2013 at 07:15:35PM +0530, Ashish Sangwan wrote: >> On Tue, Jun 18, 2013 at 9:10 PM, Theodore Ts'o <tytso@mit.edu> wrote: >> > On Fri, May 24, 2013 at 08:09:17PM +0530, ashishsangwan2@gmail.com wrote: >> >> From: Ashish Sangwan <a.sangwan@samsung.com> >> >> >> >> Both hole punch and truncate use ext4_ext_rm_leaf for removing >> >> blocks. Currently we choose the last extent as the starting >> >> point for removing blocks: ex = EXT_LAST_EXTENT(eh); >> >> This is OK for truncate but for hole punch we can optimize the >> >> extent selection as the path is already initialized. >> >> We could use this information to select proper starting extent. >> >> The code change in this patch will not affect truncate as for >> >> truncate path[depth].p_ext will always be NULL. >> >> >> >> Signed-off-by: Ashish Sangwan <a.sangwan@samsung.com> >> >> Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com> >> > >> > Applied, thanks. >> >> Sorry I cannot see the patch changes in ext4 dev branch. > > Sorry, I dropped this patch from the dev branch last night, but I > didn't want to send e-mail about it until I had completed enough > testing to be sure. It appears that this patch is causing a > regression; xfstests generic/269 and generic/279 to fail in the > nojournal configuration. > Dropping this patch makes sense until root cause is not obvious. > The tests are ones which have multiple fsstress threads racing with > dd/ENOSPC hitters, with (#270) and without (#269) quota enabled. It's > not at all obvious to me why your particular change would make a > difference here, and it may simply be that your optimization is > exposing a timing change and is not the root cause of the failure, but > I'm going to move this to the unstable portion of the patch series > until we do further investigation. > > If you could take a look at this, I would appreciate it, but as I > said, this may very well turn out not be the fault of your patch. > Sure, I will try looking into it. Regards, Ashish > Regards, > > - Ted > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] ext4: optimize extent selection for block removal in case of hole punch 2013-06-19 15:44 ` Ashish Sangwan @ 2013-06-23 18:43 ` Theodore Ts'o 0 siblings, 0 replies; 6+ messages in thread From: Theodore Ts'o @ 2013-06-23 18:43 UTC (permalink / raw) To: Ashish Sangwan; +Cc: adilger, ext4 development, Ashish Sangwan, Namjae Jeon Lukas's patch: "ext4: only zero partial blocks in ext4_zero_partial_blocks()" appears to address the failures I was seeing with xfstests 269 and 270, so I'm going to add this patch back to the ext4 git tree. Regards, - Ted ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-06-23 18:43 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-05-24 14:39 [PATCH] ext4: optimize extent selection for block removal in case of hole punch ashishsangwan2 2013-06-18 15:40 ` Theodore Ts'o 2013-06-19 13:45 ` Ashish Sangwan 2013-06-19 14:06 ` Theodore Ts'o 2013-06-19 15:44 ` Ashish Sangwan 2013-06-23 18:43 ` Theodore Ts'o
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).