Received: by 2002:a25:f815:0:0:0:0:0 with SMTP id u21csp2726912ybd; Thu, 27 Jun 2019 18:30:08 -0700 (PDT) X-Google-Smtp-Source: APXvYqyBK6ee2U7V9eQdbXQFXHxx6xXDWFrpuRARMaD9euGVxG/ykYUHzC/4vTLhvd8eHHsScvLa X-Received: by 2002:a17:90a:3688:: with SMTP id t8mr9437686pjb.35.1561685408469; Thu, 27 Jun 2019 18:30:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1561685408; cv=none; d=google.com; s=arc-20160816; b=iZMIjTjjdd6+u7E/PzmOQgo8cZmOPhXwRINiPZnqOsKpVo+u/Hk99KzkGmacUWIKVl 1vmSGWEW5Db4ONWDxOCjShRaU4CFx9nSWYIGR2klPmEGrRy8RQyjznU+ik3LWCx2dL4a jXMNikuYJ7OQgaVptZM+Ulzwa7bGTTdG2KNNxdk6yXflBApKYWlaiW3y5iVDR188qYzk sFMwFF9I63QuHW3SpSAKxFzlPtBkrOHzCgMrkoyMA3c5BmN7nvkgNvvY9dPYNdI0GGoi EgtHJaZcf/RxNfpvgHZkYLxKsyAp42syH6Wux0XZopwS45w46rS2EWRUOJ6G3ceCSD1t u1UQ== 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:to:subject; bh=vk7UKRl3ZCL3+nOed+ni1O2+vDfyWKxRQHLKA6O3Lgo=; b=O1j+ttvbrKDHQknBFhvxllnl24JgrE4lfRr7t3JAHgWFgR0KUOcVCiL+H/NJ8z5yHl YxZLL1Q1HY8zT8azlmNeZVeVDDkNJopqH2bNgXup4DIXmhGxiZRw6rcT46UxKsC+XIIE 2RtrKCKPDysEw21GSwortIMtFIR8XGZR7g49ZdsY/woLGT5HpiFXV28CUxgSV+vivd/r rNssbUn1+/2zDabAo0OLuUbPFcZZzsa0cqoX+fQdrKqb9D/Dgji5uknGgaLHhQ1v26tB 8tAZ2QVcwZvPKdVZzWFsfIL120T3qs81bKmgVoZUni8lpRpbMBsrtf9wRVk0bkzvIrOv JKIw== 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 d24si758188pgg.147.2019.06.27.18.29.49; Thu, 27 Jun 2019 18:30:08 -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 S1726668AbfF1B3i (ORCPT + 99 others); Thu, 27 Jun 2019 21:29:38 -0400 Received: from szxga05-in.huawei.com ([45.249.212.191]:19118 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726606AbfF1B3i (ORCPT ); Thu, 27 Jun 2019 21:29:38 -0400 Received: from DGGEMS413-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id B5073DD15909C132DC9D; Fri, 28 Jun 2019 09:29:35 +0800 (CST) Received: from [10.134.22.195] (10.134.22.195) by smtp.huawei.com (10.3.19.213) with Microsoft SMTP Server (TLS) id 14.3.439.0; Fri, 28 Jun 2019 09:29:26 +0800 Subject: Re: [f2fs-dev] [PATCH] f2fs: allocate blocks for pinned file To: Jaegeuk Kim , , References: <20190627170504.71700-1-jaegeuk@kernel.org> From: Chao Yu Message-ID: Date: Fri, 28 Jun 2019 09:29:58 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20190627170504.71700-1-jaegeuk@kernel.org> 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 Hi Jaegeuk, On 2019/6/28 1:05, Jaegeuk Kim wrote: > This patch allows fallocate to allocate physical blocks for pinned file. Quoted from manual of fallocate(2): " Any subregion within the range specified by offset and len that did not contain data before the call will be initialized to zero. If the FALLOC_FL_KEEP_SIZE flag is specified in mode .... Preallocating zeroed blocks beyond the end of the file in this manner is useful for optimizing append workloads. " As quoted description, our change may break the rule of fallocate(, mode = 0), because with after this change, we can't guarantee that preallocated physical block contains zeroed data Should we introduce an additional ioctl for this case? Or maybe add one more flag in fallocate() for unzeroed block preallocation, not sure. Thanks, > > Signed-off-by: Jaegeuk Kim > --- > fs/f2fs/file.c | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c > index e7c368db8185..cdfd4338682d 100644 > --- a/fs/f2fs/file.c > +++ b/fs/f2fs/file.c > @@ -1528,7 +1528,12 @@ static int expand_inode_data(struct inode *inode, loff_t offset, > if (off_end) > map.m_len++; > > - err = f2fs_map_blocks(inode, &map, 1, F2FS_GET_BLOCK_PRE_AIO); > + if (f2fs_is_pinned_file(inode)) > + map.m_seg_type = CURSEG_COLD_DATA; > + > + err = f2fs_map_blocks(inode, &map, 1, (f2fs_is_pinned_file(inode) ? > + F2FS_GET_BLOCK_PRE_DIO : > + F2FS_GET_BLOCK_PRE_AIO)); > if (err) { > pgoff_t last_off; > >