diff mbox

ext4 out of order when use cfq scheduler

Message ID 4ec8c36a910942be8d6d4745385f3cce@SGPMBX1004.APAC.bosch.com
State New, archived
Headers show

Commit Message

HUANG Weller (CM/ESW12-CN) March 16, 2016, 2:30 a.m. UTC 
> >
> > OK, I have something - Huang, can you check whether the attached
> > patches also fix your data exposure issues please? The first patch is
> > the original fix, patch two is a cleanup, patches 3 and 4 implement
> > the speedup suggested by Ted. Patches are only lightly tested so far.
> > I'll run more comprehensive tests later and in particular I want to
> > check whether the additional complexity actually brings us some
> > advantage at least for workloads which redirty pages in addition to
> > writing some new ones using delayed allocation.
> 
> OK, there was a bug in patch 3. Attached is a new version of patches 3 and 4.
> 


Hi Kara,
Patches are applied on my kernel. Basically it is working. 
Power loss test is running now. Need some days to give you test result.
At same time, Some conflicts need your confirm:

Target Kernel 3.10.63.

Patch 0004 conflicts:
----------------------------------
- Don't have function:   *mpage_map_one_extent*
So , please review this segment code at  patch 0004-ext4-Do-not-ask-jbd2-to-write-data-for-delalloc-buff.patch

@@ -1697,7 +1700,8 @@ static void mpage_da_map_and_submit(struct mpage_da_data *mpd)
 	 * So use reserved blocks to allocate metadata if possible.
 	 */
 	get_blocks_flags = EXT4_GET_BLOCKS_CREATE |
-			   EXT4_GET_BLOCKS_METADATA_NOFAIL;
+			   EXT4_GET_BLOCKS_METADATA_NOFAIL |
+			   EXT4_GET_BLOCKS_IO_SUBMIT;
 	if (ext4_should_dioread_nolock(mpd->inode))
 		get_blocks_flags |= EXT4_GET_BLOCKS_IO_CREATE_EXT;
 	if (mpd->b_state & (1 << BH_Delay))


- Don't have function *__ext4_block_zero_page_range*, so ignore the modification under this function.


Patch 0001 conflicts:
----------------------------------
- Don't have macro EXT4_GET_BLOCKS_ZERO is not available on kernel 3.10.63, so the patch is like this please help to review:


--
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

Comments

Jan Kara March 18, 2016, 9:20 a.m. UTC | #1 
On Wed 16-03-16 02:30:13, HUANG Weller (CM/ESW12-CN) wrote:
> 
> > >
> > > OK, I have something - Huang, can you check whether the attached
> > > patches also fix your data exposure issues please? The first patch is
> > > the original fix, patch two is a cleanup, patches 3 and 4 implement
> > > the speedup suggested by Ted. Patches are only lightly tested so far.
> > > I'll run more comprehensive tests later and in particular I want to
> > > check whether the additional complexity actually brings us some
> > > advantage at least for workloads which redirty pages in addition to
> > > writing some new ones using delayed allocation.
> > 
> > OK, there was a bug in patch 3. Attached is a new version of patches 3 and 4.
> > 
> 
> Patches are applied on my kernel. Basically it is working. 
> Power loss test is running now. Need some days to give you test result.

Thank you!

> At same time, Some conflicts need your confirm:

The resolution of the conflicts looks good.

								Honza
diff mbox

Patch

diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index e48bd5a..03017a9 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -751,6 +751,19 @@  has_zeroout:
 		int ret = check_block_validity(inode, map);
 		if (ret != 0)
 			return ret;
+
+		/*
+		 * Inodes with freshly allocated blocks where contents will be
+		 * visible after transaction commit must be on transaction's
+		 * ordered data list.
+		 */
+		if (map->m_flags & EXT4_MAP_NEW &&
+		    !(map->m_flags & EXT4_MAP_UNWRITTEN) &&
+		    ext4_should_order_data(inode)) {
+			ret = ext4_jbd2_file_inode(handle, inode);
+			if (ret)
+				return ret;
+		}
 	}
 	return retval;
 }