From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bombadil.infradead.org ([198.137.202.133]:44986 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751536AbeDNCiT (ORCPT ); Fri, 13 Apr 2018 22:38:19 -0400 Date: Fri, 13 Apr 2018 19:38:14 -0700 From: Matthew Wilcox To: Dave Chinner Cc: Jeff Layton , lsf-pc , Andres Freund , Andreas Dilger , "Theodore Y. Ts'o" , Ext4 Developers List , Linux FS Devel , "Joshua D. Drake" Subject: Re: fsync() errors is unsafe and risks data loss Message-ID: <20180414023814.GB997@bombadil.infradead.org> References: <190CF56C-C03D-4504-8B35-5DB479801513@dilger.ca> <20180412021752.2wykkutkmzh4ikbf@alap3.anarazel.de> <20180412030248.GA8509@bombadil.infradead.org> <1523531354.4532.21.camel@redhat.com> <20180412120122.GE23861@dastard> <1523545730.4532.82.camel@redhat.com> <20180412224404.GA5572@dastard> <1523625536.4847.21.camel@redhat.com> <20180413140232.GA24379@bombadil.infradead.org> <20180414014752.GG23861@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180414014752.GG23861@dastard> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Sat, Apr 14, 2018 at 11:47:52AM +1000, Dave Chinner wrote: > On Fri, Apr 13, 2018 at 07:02:32AM -0700, Matthew Wilcox wrote: > > 1. If we get an error while wbc->for_background is true, we should not clear > > uptodate on the page, rather SetPageError and SetPageDirty. > > So you're saying we should treat it as a transient error rather than > a permanent error. Yes, I'm proposing leaving the data in memory in case the user wants to try writing it somewhere else. > > 2. Background writebacks should skip pages which are PageError. > > That seems decidedly dodgy in the case where there is a transient > error - it requires a user to specifically run sync to get the data > to disk after the transient error has occurred. Say they don't > notice the problem because it's fleeting and doesn't cause any > obvious problems? That's fair. What I want to avoid is triggering the same error every 30 seconds (or whatever the periodic writeback threshold is set to). > e.g. XFS gets to enospc, runs out of reserve pool blocks so can't > allocate space to write back the page, then space is freed up a few > seconds later and so the next write will work just fine. > > This is a recipe for "I lost data that I wrote /days/ before the > system crashed" bug reports. So ... exponential backoff on retries? > > 3. for_sync writebacks should attempt one last write. Maybe it'll > > succeed this time. If it does, just ClearPageError. If not, we have > > somebody to report this writeback error to, and ClearPageUptodate. > > Which may well be unmount. Are we really going to wait until unmount > to report fatal errors? Goodness, no. The errors would be immediately reportable using the wb_err mechanism, as soon as the first error was encountered.