From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Chinner Subject: Re: Triggering non-integrity writeback from userspace Date: Thu, 29 Oct 2015 07:48:34 +1100 Message-ID: <20151028204834.GP8773@dastard> References: <20151022131555.GC4378@alap3.anarazel.de> <20151024213912.GE8773@dastard> <20151028092752.GF29811@alap3.anarazel.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org To: Andres Freund Return-path: Content-Disposition: inline In-Reply-To: <20151028092752.GF29811@alap3.anarazel.de> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Hi Andres, On Wed, Oct 28, 2015 at 10:27:52AM +0100, Andres Freund wrote: > On 2015-10-25 08:39:12 +1100, Dave Chinner wrote: .... > > Data integrity operations require related file metadata (e.g. block > > allocation trnascations) to be forced to the journal/disk, and a > > device cache flush issued to ensure the data is on stable storage. > > SYNC_FILE_RANGE_WRITE does neither of these things, and hence while > > the IO might be the same pattern as a data integrity operation, it > > does not provide such guarantees. > > Which is desired here - the actual integrity is still going to be done > via fsync(). OK, so you require data integrity, but.... > The idea of using SYNC_FILE_RANGE_WRITE beforehand is that > the fsync() will only have to do very little work. The language in > sync_file_range(2) doesn't inspire enough confidence for using it as an > actual integrity operation :/ So really you're trying to minimise the blocking/latency of fsync()? > > You don't want to do writeback from the syscall, right? i.e. you'd > > like to expire the inode behind the fd, and schedule background > > writeback to run on it immediately? > > Yes, that's exactly what we want. Blocking if a process has done too > much writes is fine tho. OK, so it's really the latency of the fsync() operation that is what you are trying to avoid? I've been meaning to get back to a generic implementation of an aio fsync operation: http://oss.sgi.com/archives/xfs/2014-06/msg00214.html Would that be a better approach to solving your need for a non-blocking data integrity flush of a file? Cheers, Dave. -- Dave Chinner david@fromorbit.com