Received: by 10.223.164.202 with SMTP id h10csp435491wrb; Tue, 7 Nov 2017 08:38:06 -0800 (PST) X-Google-Smtp-Source: ABhQp+SmzUGmpY7V8Y9VIK9yHSBefy8pryJ8vtv46NN+lFdy6cq1sfDeM4GZ3S/OBnahEDFhc7dQ X-Received: by 10.159.206.132 with SMTP id bg4mr18843888plb.129.1510072686736; Tue, 07 Nov 2017 08:38:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1510072686; cv=none; d=google.com; s=arc-20160816; b=fQbvlfxOPhY9ODVhizBo0WQW8ngzk7tGefmYsnkyGRalaeafpP5CNfkZKhuAJ2TDsI VVi/fcw/OnevDG6apk/HwSvqHyFJ8nn2GtB2OxdA22Ls3YxeKkdcKI9tOMecy/vg72Pm jzE5rLMZE7nVSug/E0jwZgyazONEf06mkI+4Z4knCB5iuLQQJtvfGgOhnVOK9abQnfar gTo8dfniyUS5yiW6itsu5jBkKyMewx+/IV2ycy4AwKn5HojNJgtm2p3qyOAHGi38h7uR eifJaU7ryCo2smq5dWujPYG7Y/t0SIu/BDEgpz5L28KDgT86J7sX7b8M/WNRoFImn8jP LjPw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=BOcM7brZRP+CThT5iDEyZhbmf+JJbsBW/O7BFyjgzes=; b=K4iMDClfR2DJ7IfTYvmPiEtBtjjtP6YknLYDfFgACPVQBKPej1tzQ0HVnikObf1rs1 kKf5ev06Cc/Lt+yF5oJeXNlt9pRUluHeqTFazGpheEplbKdkiXMM8E2TJiCpqUZPHkhl 0PTMYZM7eWoOhfAJ7/Pa6jaeP6lLQo5qPP74oZoMnjBk7o26Qm3/aZD09nJ0+rzqPCVG 3ydnRUVLvDf0dKb61/PeRn4nZ0CLud2lw3ePh2f1a343CC/3gw5NAt2WA57mfUNFAdbn 4m67nsRqKlYtRJsm7lpEutBD55ZCR5mgsubi893XEsSmiIPPoZ/y9dCg1DA1mLMWB70/ 3trw== 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 l4si1739613pln.441.2017.11.07.08.37.54; Tue, 07 Nov 2017 08:38:06 -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 S932620AbdKGDLf (ORCPT + 91 others); Mon, 6 Nov 2017 22:11:35 -0500 Received: from szxga04-in.huawei.com ([45.249.212.190]:9965 "EHLO szxga04-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753392AbdKGDLe (ORCPT ); Mon, 6 Nov 2017 22:11:34 -0500 Received: from 172.30.72.59 (EHLO DGGEMS404-HUB.china.huawei.com) ([172.30.72.59]) by dggrg04-dlp.huawei.com (MOS 4.4.6-GA FastPath queued) with ESMTP id DKJ43481; Tue, 07 Nov 2017 11:11:11 +0800 (CST) Received: from [127.0.0.1] (10.111.220.140) by DGGEMS404-HUB.china.huawei.com (10.3.19.204) with Microsoft SMTP Server id 14.3.361.1; Tue, 7 Nov 2017 11:10:14 +0800 Subject: Re: [PATCH v3] f2fs: fix out-of-free problem caused by atomic write To: Jaegeuk Kim CC: , , , , , , , References: <1509934071-116656-1-git-send-email-yunlong.song@huawei.com> <20171107015543.GB88544@jaegeuk-macbookpro.roam.corp.google.com> <54e2f05e-f5be-68ac-9115-0c70ab6c8082@huawei.com> <20171107024925.GI88544@jaegeuk-macbookpro.roam.corp.google.com> From: Yunlong Song Message-ID: <42e3aaea-9210-805a-7bf0-d51efa4efcda@huawei.com> Date: Tue, 7 Nov 2017 11:10:07 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20171107024925.GI88544@jaegeuk-macbookpro.roam.corp.google.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: [10.111.220.140] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.5A01244F.004F,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 05473afb3808bb82628cfc5b31ae52df Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org I test it in an old kernel and find it hangs in gc process, maybe it is a bug of old kernel. On 2017/11/7 10:49, Jaegeuk Kim wrote: > On 11/07, Yunlong Song wrote: >> This patch tries its best to collect prefree segments and make it free to be >> used >> in the commit process, or it will use up free segments since prefree >> segments >> can not be used during commit process. >> >> As for your suggestion, I do consider that in an initial patch which does >> not send >> out, but I am afraid that will lead to long latency if the atomic file is >> large and the >> device is almost full and fragmented. > Why? f2fs_balance_fs() would be fine to return, if target # of segments can > be found from prefree_segments() by checkpoint like what you did. Otherwise, > it needs to call f2fs_gc(). > >> On 2017/11/7 9:55, Jaegeuk Kim wrote: >>> On 11/06, Yunlong Song wrote: >>>> f2fs_balance_fs only actives once in the commit_inmem_pages, but there >>>> are more than one page to commit, so all the other pages will miss the >>>> check. This will lead to out-of-free problem when commit a very large >>>> file. However, we cannot do f2fs_balance_fs for each inmem page, since >>>> this will break atomicity. As a result, we should collect prefree >>>> segments if needed. >>>> >>>> Signed-off-by: Yunlong Song >>>> --- >>>> fs/f2fs/f2fs.h | 1 + >>>> fs/f2fs/segment.c | 24 +++++++++++++++++++++++- >>>> 2 files changed, 24 insertions(+), 1 deletion(-) >>>> >>>> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h >>>> index 13a96b8..04ce48f 100644 >>>> --- a/fs/f2fs/f2fs.h >>>> +++ b/fs/f2fs/f2fs.h >>>> @@ -610,6 +610,7 @@ struct f2fs_inode_info { >>>> struct list_head inmem_pages; /* inmemory pages managed by f2fs */ >>>> struct task_struct *inmem_task; /* store inmemory task */ >>>> struct mutex inmem_lock; /* lock for inmemory pages */ >>>> + unsigned long inmem_blocks; /* inmemory blocks */ >>>> struct extent_tree *extent_tree; /* cached extent_tree entry */ >>>> struct rw_semaphore dio_rwsem[2];/* avoid racing between dio and gc */ >>>> struct rw_semaphore i_mmap_sem; >>>> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c >>>> index 46dfbca..b87ede4 100644 >>>> --- a/fs/f2fs/segment.c >>>> +++ b/fs/f2fs/segment.c >>>> @@ -210,6 +210,7 @@ void register_inmem_page(struct inode *inode, struct page *page) >>>> list_add_tail(&fi->inmem_ilist, &sbi->inode_list[ATOMIC_FILE]); >>>> spin_unlock(&sbi->inode_lock[ATOMIC_FILE]); >>>> inc_page_count(F2FS_I_SB(inode), F2FS_INMEM_PAGES); >>>> + fi->inmem_blocks++; >>>> mutex_unlock(&fi->inmem_lock); >>>> trace_f2fs_register_inmem_page(page, INMEM); >>>> @@ -221,6 +222,7 @@ static int __revoke_inmem_pages(struct inode *inode, >>>> struct f2fs_sb_info *sbi = F2FS_I_SB(inode); >>>> struct inmem_pages *cur, *tmp; >>>> int err = 0; >>>> + struct f2fs_inode_info *fi = F2FS_I(inode); >>>> list_for_each_entry_safe(cur, tmp, head, list) { >>>> struct page *page = cur->page; >>>> @@ -263,6 +265,7 @@ static int __revoke_inmem_pages(struct inode *inode, >>>> list_del(&cur->list); >>>> kmem_cache_free(inmem_entry_slab, cur); >>>> dec_page_count(F2FS_I_SB(inode), F2FS_INMEM_PAGES); >>>> + fi->inmem_blocks--; >>>> } >>>> return err; >>>> } >>>> @@ -302,6 +305,10 @@ void drop_inmem_pages(struct inode *inode) >>>> if (!list_empty(&fi->inmem_ilist)) >>>> list_del_init(&fi->inmem_ilist); >>>> spin_unlock(&sbi->inode_lock[ATOMIC_FILE]); >>>> + if (fi->inmem_blocks) { >>>> + f2fs_bug_on(sbi, 1); >>>> + fi->inmem_blocks = 0; >>>> + } >>>> mutex_unlock(&fi->inmem_lock); >>>> clear_inode_flag(inode, FI_ATOMIC_FILE); >>>> @@ -326,6 +333,7 @@ void drop_inmem_page(struct inode *inode, struct page *page) >>>> f2fs_bug_on(sbi, !cur || cur->page != page); >>>> list_del(&cur->list); >>>> + fi->inmem_blocks--; >>>> mutex_unlock(&fi->inmem_lock); >>>> dec_page_count(sbi, F2FS_INMEM_PAGES); >>>> @@ -410,6 +418,16 @@ int commit_inmem_pages(struct inode *inode) >>>> INIT_LIST_HEAD(&revoke_list); >>>> f2fs_balance_fs(sbi, true); >>>> + if (prefree_segments(sbi) >>>> + && has_not_enough_free_secs(sbi, 0, >>>> + fi->inmem_blocks / BLKS_PER_SEC(sbi))) { >>>> + struct cp_control cpc; >>>> + >>>> + cpc.reason = __get_cp_reason(sbi); >>>> + err = write_checkpoint(sbi, &cpc); >>>> + if (err) >>>> + goto drop; >>> What do you want to guarantee with this? How about passing target # of segments >>> into f2fs_balance_fs() so that f2fs_gc() could secure wanted free space in a >>> loop? >>> >>> Thanks, >>> >>>> + } >>>> f2fs_lock_op(sbi); >>>> set_inode_flag(inode, FI_ATOMIC_COMMIT); >>>> @@ -429,7 +447,7 @@ int commit_inmem_pages(struct inode *inode) >>>> ret = __revoke_inmem_pages(inode, &revoke_list, false, true); >>>> if (ret) >>>> err = ret; >>>> - >>>> +drop: >>>> /* drop all uncommitted pages */ >>>> __revoke_inmem_pages(inode, &fi->inmem_pages, true, false); >>>> } >>>> @@ -437,6 +455,10 @@ int commit_inmem_pages(struct inode *inode) >>>> if (!list_empty(&fi->inmem_ilist)) >>>> list_del_init(&fi->inmem_ilist); >>>> spin_unlock(&sbi->inode_lock[ATOMIC_FILE]); >>>> + if (fi->inmem_blocks) { >>>> + f2fs_bug_on(sbi, 1); >>>> + fi->inmem_blocks = 0; >>>> + } >>>> mutex_unlock(&fi->inmem_lock); >>>> clear_inode_flag(inode, FI_ATOMIC_COMMIT); >>>> -- >>>> 1.8.5.2 >>> . >>> >> -- >> Thanks, >> Yunlong Song >> > . > -- Thanks, Yunlong Song From 1583425913802004662@xxx Tue Nov 07 16:37:05 +0000 2017 X-GM-THRID: 1582330312060990093 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread