From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fieldses.org ([173.255.197.46]:37070 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751232AbeDRSJD (ORCPT ); Wed, 18 Apr 2018 14:09:03 -0400 Date: Wed, 18 Apr 2018 14:09:03 -0400 To: Andres Freund Cc: Andreas Dilger , 20180410184356.GD3563@thunk.org, "Theodore Y. Ts'o" , Ext4 Developers List , Linux FS Devel , Jeff Layton , "Joshua D. Drake" Subject: Re: fsync() errors is unsafe and risks data loss Message-ID: <20180418180903.GD9897@fieldses.org> References: <20180410220726.vunhvwuzxi5bm6e5@alap3.anarazel.de> <190CF56C-C03D-4504-8B35-5DB479801513@dilger.ca> <20180412021752.2wykkutkmzh4ikbf@alap3.anarazel.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180412021752.2wykkutkmzh4ikbf@alap3.anarazel.de> From: bfields@fieldses.org (J. Bruce Fields) Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Wed, Apr 11, 2018 at 07:17:52PM -0700, Andres Freund wrote: > Hi, > > On 2018-04-11 15:52:44 -0600, Andreas Dilger wrote: > > On Apr 10, 2018, at 4:07 PM, Andres Freund wrote: > > > 2018-04-10 18:43:56 Ted wrote: > > >> So for better or for worse, there has not been as much investment in > > >> buffered I/O and data robustness in the face of exception handling of > > >> storage devices. > > > > > > That's a bit of a cop out. It's not just databases that care. Even more > > > basic tools like SCM, package managers and editors care whether they can > > > proper responses back from fsync that imply things actually were synced. > > > > Sure, but it is mostly PG that is doing (IMHO) crazy things like writing > > to thousands(?) of files, closing the file descriptors, then expecting > > fsync() on a newly-opened fd to return a historical error. > > It's not just postgres. dpkg (underlying apt, on debian derived distros) > to take an example I just randomly guessed, does too: > /* We want to guarantee the extracted files are on the disk, so that the > * subsequent renames to the info database do not end up with old or zero > * length files in case of a system crash. As neither dpkg-deb nor tar do > * explicit fsync()s, we have to do them here. > * XXX: This could be avoided by switching to an internal tar extractor. */ > dir_sync_contents(cidir); > > (a bunch of other places too) > > Especially on ext3 but also on newer filesystems it's performancewise > entirely infeasible to fsync() every single file individually - the > performance becomes entirely attrocious if you do that. Is that still true if you're able to use some kind of parallelism? (async io, or fsync from multiple processes?) --b.