Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp628369ybf; Fri, 28 Feb 2020 04:46:20 -0800 (PST) X-Google-Smtp-Source: APXvYqyWw23ic1DaMuespG/GI1sj4y9sR6ARNz49B1DKASICvThBlcEelglU94M/Mi/8HRRUkpmz X-Received: by 2002:a9d:7cd9:: with SMTP id r25mr2999030otn.326.1582893980813; Fri, 28 Feb 2020 04:46:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582893980; cv=none; d=google.com; s=arc-20160816; b=aQTyBTbaJDNdpgq0EU0gQdY8nXj5HWFcn0rlTMGEr/BEbvHztIPufXTgDuOw0kGPuO SCAzb23MYPGpBMaMBrF6Fj8lCpbq1kEQOZE4kowKrhxapXltePZodrKbHZA1L9Ot0zf5 YIohmF3R0b5EI6xsQa+Be0+3juRLN/Mwoz3xugPKVtCImNLkhiGIDsVOFfogWsB09DEd VOcdCQp860scBs9rd+wBTt0ts9r7rThrseiqaTI+1gQEl8cnzD4Ad0tJjqwVP+7HNm7G 7gGueM7swVV+5n1OZAJD+s7ueVYHtn4zcIDOgRQslFI77dwHrP3B2YZa9UMKPbGbdGFI PtgA== 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; bh=PR+OjGISFviSqzLuywc+GlhDDbIOQldtNQMvowFeq4E=; b=TS8BOERNNaKUNVMNa/w9ybIU2F8UVqogqPzSu9+yX5G7l4F7XLbFGfI6iXaPokF3sW qEje43eUQsAi4nFZksJFMAewn6CS1/xc1MmTJonxL5625Iay7fadl3bGzLkJKleWxjWX Rb7MjKgMCsn+rHr5w4RGW7fkpUk3H2V7YdUCphZtkDTpYeC75yagcp/Twf/FLPj0OgbW 07+RFiv4lGrMip0AfWDox5jxMMMMnvMp33lmGEgsd7zHoojMUQhwcZEX0SRpqbxPYkK1 8hQ6BIwqw3Tzl9h1/ujPDlhy/4mNAGVmX6XcOOrgoX9BhmlpD72ecDOjTwZwN87xihTM 7G8Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=virtuozzo.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g6si1388134otk.171.2020.02.28.04.46.09; Fri, 28 Feb 2020 04:46:20 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-ext4-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-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=virtuozzo.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725856AbgB1MqG (ORCPT + 99 others); Fri, 28 Feb 2020 07:46:06 -0500 Received: from relay.sw.ru ([185.231.240.75]:51230 "EHLO relay.sw.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725730AbgB1MqG (ORCPT ); Fri, 28 Feb 2020 07:46:06 -0500 Received: from dhcp-172-16-24-104.sw.ru ([172.16.24.104]) by relay.sw.ru with esmtp (Exim 4.92.3) (envelope-from ) id 1j7f1l-00051W-Cu; Fri, 28 Feb 2020 15:46:01 +0300 Subject: Re: [PATCH RFC 0/5] fs, ext4: Physical blocks placement hint for fallocate(0): fallocate2(). TP defrag. To: xiaohui li Cc: "Theodore Y. Ts'o" , viro@zeniv.linux.org.uk, adilger.kernel@dilger.ca, snitzer@redhat.com, jack@suse.cz, ebiggers@google.com, riteshh@linux.ibm.com, krisman@collabora.com, surajjs@amazon.com, dmonakhov@gmail.com, mbobrowski@mbobrowski.org, enwlinux@gmail.com, sblbir@amazon.com, khazhy@google.com, Ext4 Developers List , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org References: <158272427715.281342.10873281294835953645.stgit@localhost.localdomain> From: Kirill Tkhai Message-ID: Date: Fri, 28 Feb 2020 15:46:01 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org Hi, Xiaohui, On 28.02.2020 10:07, xiaohui li wrote: > hi Kirill Tkhai: > > I agree with your idea very much. > I had also implemented a similar fallocate interface with the unique > flag which call tell ext4 filesystems to allocate the special free > physical extents. > I had done the same work as your fallocate2 work last year. > > but i think it has modified the core ext4 physical blocks allocator a > lot, so the ext4 community may not accept it. > so I didn't share it openly. > > but i think this fallocate2 interface just same as my work is also > very useful in android mobile phone world. > > today android phone has large capacity memory and storage, just the > same as a computer. > and current days, customer treat phone and make full use of it by just > the same way as they treat computer in past days. > so after install many software and unstall them for many times in > android phone, the ext4 physical layout on disk has become more > fragmented > (the number of extents per group is large). > at this moment, when run a sequential write workload, you will find > the sequential write performance is very bad. > > but after do defragment work on some fragmented ext4 groups, and then > run the same workload again, the sequential write performance has > improved greatly. > and the fallocate2 interface is a necessary component of this > defragment work shown above. > > so i also think this fallocate2 interface is an important and useful > tools for ext4 filesystems. I hope fs people in their comments will help to formulate an interface, which is suitable fs philosophy and for our necessities. Do you have your defrag util hosted on some of github repositories? Kirill