From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756166AbbJ1Usi (ORCPT ); Wed, 28 Oct 2015 16:48:38 -0400 Received: from ipmail06.adl2.internode.on.net ([150.101.137.129]:33335 "EHLO ipmail06.adl2.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751297AbbJ1Ush (ORCPT ); Wed, 28 Oct 2015 16:48:37 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2BjBwDZMzFWPEcHLHleKAGDDVRvjQ6dGQaLKosvIYV0BAICgTxNAQEBAQEBBwEBAQFBP4Q1AQEBAwE6HCMFCwgDGAklDwUlAwcaE4goBw7GHQEBAQcCIRmGF4VFgnGBVkkHhC4Flj2FHIgAgWGWa4NwhHsqNAGENIFIAQEB Date: Thu, 29 Oct 2015 07:48:34 +1100 From: Dave Chinner To: Andres Freund Cc: linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: Triggering non-integrity writeback from userspace 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 Content-Disposition: inline In-Reply-To: <20151028092752.GF29811@alap3.anarazel.de> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@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