Received: by 10.223.176.5 with SMTP id f5csp1561650wra; Sun, 4 Feb 2018 06:58:54 -0800 (PST) X-Google-Smtp-Source: AH8x225k67v1p94KVBXbMtJtWyRpl0dOtJibJXYLnsz2KhumrgwNWO4EYGT4drDCJb+r5DJ1EhyB X-Received: by 2002:a17:902:8585:: with SMTP id e5-v6mr24201750plo.165.1517756334598; Sun, 04 Feb 2018 06:58:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517756334; cv=none; d=google.com; s=arc-20160816; b=h+qbYaWI4tmPP5b9NDAP9O87POzBfy6BtAFrj/cSmwyXcnjOo3ljcaKejb4za0kpCa Hu+kIFsNe7gPcK8/QP8obvYqSvsIFeHiqpC67W4YJI4zWGwFw2XVFhmPD6KKH4mLAUNb 5WsCJlhY2emZxwEmm8YIhdag+POtiWkPV0jnRlQOyhW1merIQoAkfqgC6/7Houj1wgN8 wWwjIHKEL2MT/pIBZ5hz/73WqYZbrk8SIGu/0f7NdT6kkJVJP85fl69KK2t44IZH2BdD PKWF8UOECws/E7oB14UgM/x36tmEYiaPCNJbSa1irdguKsHgHM+rVt2ZPTTRB/TtCMZj 9wmA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dmarc-filter :arc-authentication-results; bh=NNy/LqcAM4a2nlXcZkg3/bahKVprekFVnfGJ83N7+e0=; b=sORzXC/ohrSz43jbXd6SX45uS/zTjnGk4LiinM5j1HyYaWmnA9uEUc/pvoXV31yd9i xxWQzYn7QUsYSTAMyJYlY0k7BxPJ0GN/wGG3RwlqHpdhcDNFBP4BOGvkVRKRHiuMFKw8 ld6W2cr446S4+tC1kYDRfxt4KNfmy8k9oa50Gaw6CkLSwovRNgeJJJiSw4zgIxPU0P9r bzxLcU5xtonflJT2SUJNLWQ1a1ma0yYt7GfUuNlUV+oY+hPFbDXQiGydxGmZcpm+P+E2 mUK4zjKV3OmJMus6ZSl8wH+QfBM0Vacne1/CytrqLw5VRNMqaxKwzhyY4e/OMu90M7DG 7OmA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o2-v6si5315188plk.235.2018.02.04.06.58.26; Sun, 04 Feb 2018 06:58:54 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751872AbeBDO5D (ORCPT + 99 others); Sun, 4 Feb 2018 09:57:03 -0500 Received: from mail.kernel.org ([198.145.29.99]:48994 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750888AbeBDO5A (ORCPT ); Sun, 4 Feb 2018 09:57:00 -0500 Received: from [192.168.0.101] (unknown [49.77.178.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id CC029217AB; Sun, 4 Feb 2018 14:56:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CC029217AB Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=chao@kernel.org Subject: Re: [PATCH 1/2] f2fs: enable to gc page whose inode already atomic commit To: Yunlong Song , jaegeuk@kernel.org, yuchao0@huawei.com, yunlong.song@icloud.com Cc: miaoxie@huawei.com, bintian.wang@huawei.com, shengyong1@huawei.com, heyunlei@huawei.com, linux-f2fs-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org References: <1517626068-49739-1-git-send-email-yunlong.song@huawei.com> From: Chao Yu Message-ID: Date: Sun, 4 Feb 2018 22:56:37 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <1517626068-49739-1-git-send-email-yunlong.song@huawei.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018/2/3 10:47, Yunlong Song wrote: > If inode has already started to atomic commit, then set_page_dirty will > not mix the gc pages with the inmem atomic pages, so the page can be > gced safely. Let's avoid Ccing fs mailing list if the patch didn't change vfs common codes. As you know, the problem here is mixed dnode block flushing w/o writebacking gced data block, result in making transaction unintegrated. So how about just using dio_rwsem[WRITE] during atomic committing to exclude GCing data block of atomic opened file? Thanks, > > Signed-off-by: Yunlong Song > --- > fs/f2fs/data.c | 5 ++--- > fs/f2fs/gc.c | 6 ++++-- > 2 files changed, 6 insertions(+), 5 deletions(-) > > diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c > index 7435830..edafcb6 100644 > --- a/fs/f2fs/data.c > +++ b/fs/f2fs/data.c > @@ -1580,14 +1580,13 @@ bool should_update_outplace(struct inode *inode, struct f2fs_io_info *fio) > return true; > if (S_ISDIR(inode->i_mode)) > return true; > - if (f2fs_is_atomic_file(inode)) > - return true; > if (fio) { > if (is_cold_data(fio->page)) > return true; > if (IS_ATOMIC_WRITTEN_PAGE(fio->page)) > return true; > - } > + } else if (f2fs_is_atomic_file(inode)) > + return true; > return false; > } > > diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c > index b9d93fd..84ab3ff 100644 > --- a/fs/f2fs/gc.c > +++ b/fs/f2fs/gc.c > @@ -622,7 +622,8 @@ static void move_data_block(struct inode *inode, block_t bidx, > if (!check_valid_map(F2FS_I_SB(inode), segno, off)) > goto out; > > - if (f2fs_is_atomic_file(inode)) > + if (f2fs_is_atomic_file(inode) && > + !f2fs_is_commit_atomic_write(inode)) > goto out; > > if (f2fs_is_pinned_file(inode)) { > @@ -729,7 +730,8 @@ static void move_data_page(struct inode *inode, block_t bidx, int gc_type, > if (!check_valid_map(F2FS_I_SB(inode), segno, off)) > goto out; > > - if (f2fs_is_atomic_file(inode)) > + if (f2fs_is_atomic_file(inode) && > + !f2fs_is_commit_atomic_write(inode)) > goto out; > if (f2fs_is_pinned_file(inode)) { > if (gc_type == FG_GC) >