From patchwork Wed Mar 16 02:30:13 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "HUANG Weller (CM/ESW12-CN)" X-Patchwork-Id: 598107 Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 3qPwVR1FhKz9ssM for ; Wed, 16 Mar 2016 13:31:57 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934089AbcCPCaT (ORCPT ); Tue, 15 Mar 2016 22:30:19 -0400 Received: from smtp6-v.fe.bosch.de ([139.15.237.11]:15728 "EHLO smtp6-v.fe.bosch.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932068AbcCPCaS convert rfc822-to-8bit (ORCPT ); Tue, 15 Mar 2016 22:30:18 -0400 Received: from vsmta12.fe.internet.bosch.com (unknown [10.4.98.52]) by imta23.fe.bosch.de (Postfix) with ESMTP id C828D1580002; Wed, 16 Mar 2016 03:30:15 +0100 (CET) Received: from FE-MBX1011.de.bosch.com (vsgw23.fe.internet.bosch.com [10.4.98.23]) by vsmta12.fe.internet.bosch.com (Postfix) with ESMTP id AE9391B80425; Wed, 16 Mar 2016 03:30:15 +0100 (CET) Received: from SGPMBX1001.APAC.bosch.com (10.187.56.31) by FE-MBX1011.de.bosch.com (10.3.230.69) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 16 Mar 2016 03:30:15 +0100 Received: from SGPMBX1004.APAC.bosch.com (10.187.56.34) by SGPMBX1001.APAC.bosch.com (10.187.56.31) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 16 Mar 2016 10:30:14 +0800 Received: from SGPMBX1004.APAC.bosch.com ([fe80::9909:67f3:6dff:f747]) by SGPMBX1004.APAC.bosch.com ([fe80::9909:67f3:6dff:f747%21]) with mapi id 15.00.1104.000; Wed, 16 Mar 2016 10:30:14 +0800 From: "HUANG Weller (CM/ESW12-CN)" To: Jan Kara , Theodore Ts'o CC: "linux-ext4@vger.kernel.org" , "Li, Michael" Subject: RE: ext4 out of order when use cfq scheduler Thread-Topic: ext4 out of order when use cfq scheduler Thread-Index: AdE8fQsAcg56aA4fSC6S5u509zsJoAACWrKAACVuvRACZP5nAAA2tXcAACfy3kD///gVgP/+Jv1ggANwXgD//3RXsIAAouwAgGc+4ICAAcgAAIAAdIqAgAFSEQCAAEMNgIAAWlSA//8ayQA= Date: Wed, 16 Mar 2016 02:30:13 +0000 Message-ID: <4ec8c36a910942be8d6d4745385f3cce@SGPMBX1004.APAC.bosch.com> References: <20160106100621.GA24046@quack.suse.cz> <3ab48fa47e434455b101251730e69bd2@SGPMBX1004.APAC.bosch.com> <20160107102420.GB8380@quack.suse.cz> <20160107114736.GC8380@quack.suse.cz> <20160313042723.GC29218@thunk.org> <20160314073928.GD5213@quack.suse.cz> <20160314143635.GM29218@thunk.org> <20160315104634.GG17942@quack.suse.cz> <20160315144633.GA12352@quack.suse.cz> <20160315200951.GA1445@quack.suse.cz> In-Reply-To: <20160315200951.GA1445@quack.suse.cz> Accept-Language: en-US, en-SG Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.173.87.59] MIME-Version: 1.0 X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22194.006 X-TMASE-MatchedRID: UuaOI1zLN1gA9DcflZdnSZpWgCLYjjT9I0SxEIayEwvfc2Xd6VJ+ymbZ 7nkhVnWgKQyonLE26Xrem+7Io4TyUEk8cutMZdwNTSPNp9e/u1MfOdo4H355iDv2eZ6DNuCbRVR 6g0VK1rM1tyreFpy1k1AWbUPD+zvaYsVTdA0JRIS4jAucHcCqnQvxMaV6x4s8WltirZ/iPP66bB qJCvgv/6rYYt9g0UiCy4RVJiONy1FP6qceA7YxiefHZObG8Jsov8jdqvFOu+LJYIv7y0tu9t9wM gmVVNxuzWKIZvkfm60v3ndkA41Ccge8DFR77Tc9jFUG+PWNtyMWyk90TI5HWjydvUg+VfSm2d8m tRIRsUP+nsWBnV+HV7OhPROFI1ULXHEPHmpuRH3+xOhjarOnHtd7An+xRmXW+gtHj7OwNO0CpgE TeT0ynA== Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org > > > > 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 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; }