From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B0EF3C432C2 for ; Wed, 25 Sep 2019 12:54:28 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 787E62146E for ; Wed, 25 Sep 2019 12:54:28 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 787E62146E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=mit.edu Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 10CDC6B0266; Wed, 25 Sep 2019 08:54:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0964C6B0269; Wed, 25 Sep 2019 08:54:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E77826B026B; Wed, 25 Sep 2019 08:54:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0215.hostedemail.com [216.40.44.215]) by kanga.kvack.org (Postfix) with ESMTP id BF17C6B0266 for ; Wed, 25 Sep 2019 08:54:27 -0400 (EDT) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with SMTP id 5355E824CA3F for ; Wed, 25 Sep 2019 12:54:27 +0000 (UTC) X-FDA: 75973436574.11.use68_9be04295602b X-HE-Tag: use68_9be04295602b X-Filterd-Recvd-Size: 4217 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by imf07.hostedemail.com (Postfix) with ESMTP for ; Wed, 25 Sep 2019 12:54:26 +0000 (UTC) Received: from callcc.thunk.org (guestnat-104-133-0-98.corp.google.com [104.133.0.98] (may be forged)) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x8PCsAFi024978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 25 Sep 2019 08:54:17 -0400 Received: by callcc.thunk.org (Postfix, from userid 15806) id D5A834200BF; Wed, 25 Sep 2019 08:54:09 -0400 (EDT) Date: Wed, 25 Sep 2019 08:54:09 -0400 From: "Theodore Y. Ts'o" To: Dave Chinner Cc: Konstantin Khlebnikov , Tejun Heo , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Jens Axboe , Michal Hocko , Mel Gorman , Johannes Weiner , Linus Torvalds Subject: Re: [PATCH v2] mm: implement write-behind policy for sequential file writes Message-ID: <20190925125409.GD18094@mit.edu> References: <156896493723.4334.13340481207144634918.stgit@buzz> <875f3b55-4fe1-e2c3-5bee-ca79e4668e72@yandex-team.ru> <20190923145242.GF2233839@devbig004.ftw2.facebook.com> <20190924073940.GM6636@dread.disaster.area> <20190925071854.GC804@dread.disaster.area> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190925071854.GC804@dread.disaster.area> User-Agent: Mutt/1.10.1 (2018-07-13) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Sep 25, 2019 at 05:18:54PM +1000, Dave Chinner wrote: > > > ANd, really such strict writebehind behaviour is going to cause all > > > sorts of unintended problesm with filesystems because there will be > > > adverse interactions with delayed allocation. We need a substantial > > > amount of dirty data to be cached for writeback for fragmentation > > > minimisation algorithms to be able to do their job.... > > > > I think most sequentially written files never change after close. > > There are lots of apps that write zeros to initialise and allocate > space, then go write real data to them. Database WAL files are > commonly initialised like this... Fortunately, most of the time Enterprise Database files which are initialized with a fd which is then kept open. And it's only a single file. So that's a hueristic that's not too bad to handle so long as it's only triggered when there are no open file descriptors on said inode. If something is still keeping the file open, then we do need to be very careful about writebehind. That behind said, with databases, they are goind to be calling fdatasync(2) and fsync(2) all the time, so it's unlikely writebehind is goint to be that much of an issue, so long as the max writebehind knob isn't set too insanely low. It's been over ten years since I last looked at this, and so things may have very likely changed, but one enterprise database I looked at would fallocate 32M, and then write 32M of zeros to make sure blocks were marked as initialized, so that further random writes wouldn't cause metadata updates. Now, there *are* applications which log to files via append, and in the worst case, they don't actually keep a fd open. Examples of this would include scripts that call logger(1) very often. But in general, taking into account whether or not there is still a fd holding the inode open to influence how aggressively we do writeback does make sense. Finally, we should remember that this will impact battery life on laptops. Perhaps not so much now that most laptops have SSD's instead of HDD's, but aggressive writebehind does certainly have tradeoffs, and what makes sense for a NVMe attached SSD is going to be very different for a $2 USB thumb drive picked up at the checkout aisle of Staples.... - Ted