Received: by 10.192.165.148 with SMTP id m20csp225803imm; Thu, 19 Apr 2018 20:16:19 -0700 (PDT) X-Google-Smtp-Source: AIpwx481iyScMdB9DL7KE8Y/DqTXOXFOsT658oIByQRkimhN6Xd4IKuLagSSOHrEe1VmPu3vbkX9 X-Received: by 10.99.143.77 with SMTP id r13mr7010348pgn.375.1524194179026; Thu, 19 Apr 2018 20:16:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524194178; cv=none; d=google.com; s=arc-20160816; b=V5MsbpUXuDznuFlNtGORx3oo7Wx1UGq2JWqWjK2gJVmn7HfoKWsF5CHEwKSr4ItqZ+ GvYW0EpgP7XBYl09e1rNPA6BzrmTGoRk6s48lZMRgDkGAT/505SxvquRrgCxAsFROxch RobJmud0cWEk07JW1qQTvT+5jbhbE/Eq5AlImn2eHskaPEaW8Vsb8KKCgWan2gwmhmrr my11A7vw5UV9UYNHyfCNbDykcu68fGvM5bHwsaow7/mJyCsylw4dl9CzivI2U4h8r5ww HONe09MYFWe2HDK4w058TRhBMKE9xJw92XABZ6yg6ycGPLqWK6yeqCe7LRlOygupiWXG co9g== 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:arc-authentication-results; bh=ECncPh6bV8+xotocztdInl6YlpHVVhVYwPKgRqfyrdM=; b=gn8QqTSOXmSrGZsm1ItD34fNl66GsqjyH0FKbQhG+/Rf3CxCMFFxuUN8Fxs1rEWiWX Y4bie6C6U+Yg6TnVcHCcp+z+muG/TL1/irHWbD8Hjpyo3qxxtYgoy0SuB1IfV27D/ly5 SaaR9mGE69NMAwDKWkbDbVjbFDuceBoJYoSNZpEJ2bQm/Ldu710A4L3WYXMR1CJiKXz8 8uZg8neuSIw6bYFyDGDE0pOC3z7uWFQZl1biLOeNajuW3q6r7T+fN7zG8gJyWZDBwgBU cKKf6LbZZ0eEuRePEWxxPzytEbgvyQjzqOM9ugYSZhK6Ct8VEFc3WImQjlHNXLat8pzi dZwQ== 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 e8si4156500pgf.679.2018.04.19.20.16.04; Thu, 19 Apr 2018 20:16:18 -0700 (PDT) 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 S1754157AbeDTDO6 (ORCPT + 99 others); Thu, 19 Apr 2018 23:14:58 -0400 Received: from szxga07-in.huawei.com ([45.249.212.35]:57696 "EHLO huawei.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1753964AbeDTDO5 (ORCPT ); Thu, 19 Apr 2018 23:14:57 -0400 Received: from DGGEMS403-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id B18C42C97B9E9; Fri, 20 Apr 2018 11:14:53 +0800 (CST) Received: from [127.0.0.1] (10.134.22.195) by DGGEMS403-HUB.china.huawei.com (10.3.19.203) with Microsoft SMTP Server id 14.3.361.1; Fri, 20 Apr 2018 11:14:48 +0800 Subject: Re: [f2fs-dev] [PATCH] f2fs: sepearte hot/cold in free nid To: heyunlei , "jaegeuk@kernel.org" CC: "linux-kernel@vger.kernel.org" , "linux-f2fs-devel@lists.sourceforge.net" References: <20180420015231.90679-1-yuchao0@huawei.com> <42B685BFA705F94C860C6DD0752F056548377C3C@DGGEMA503-MBS.china.huawei.com> From: Chao Yu Message-ID: Date: Fri, 20 Apr 2018 11:14:52 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <42B685BFA705F94C860C6DD0752F056548377C3C@DGGEMA503-MBS.china.huawei.com> Content-Type: text/plain; charset="windows-1252" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.134.22.195] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018/4/20 10:30, heyunlei wrote: > > >> -----Original Message----- >> From: Chao Yu [mailto:yuchao0@huawei.com] >> Sent: Friday, April 20, 2018 9:53 AM >> To: jaegeuk@kernel.org >> Cc: linux-kernel@vger.kernel.org; linux-f2fs-devel@lists.sourceforge.net >> Subject: [f2fs-dev] [PATCH] f2fs: sepearte hot/cold in free nid >> >> As most indirect node, dindirect node, and xattr node won't be updated >> after they are created, but inode node and other direct node will change >> more frequently, so store their nat entries mixedly in whole nat table >> will suffer: >> - fragment nat table soon due to different update rate >> - more nat block update due to fragmented nat table >> > > BTW, should we enable this patch: f2fs: reuse nids more aggressively? > > I think it will decrease nat area fragment and will decrease io of nat? For a fragmented nat table, there will be no different in between reusing obsolete nid or allocating nid from next nat block. IMO, in order to decrease nat block write, it needs to add more allocation algorithm like a filesystem does, but firstly, I'd like to separate hot entry from cold one. Thanks,