From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jamie Lokier Subject: Re: [rfc] fsync_range? Date: Wed, 21 Jan 2009 12:09:58 +0000 Message-ID: <20090121120958.GC8609@shareable.org> References: <20090120164726.GA24891@wotan.suse.de> <20090120183120.GD27464@shareable.org> <20090121012900.GD24891@wotan.suse.de> <20090121031500.GA2354@shareable.org> <20090121034835.GG24891@wotan.suse.de> <20090121052401.GB3944@shareable.org> <20090121061632.GJ24891@wotan.suse.de> <20090121111802.GA8609@shareable.org> <20090121114122.GS24891@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org To: Nick Piggin Return-path: Received: from mail2.shareable.org ([80.68.89.115]:40914 "EHLO mail2.shareable.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755719AbZAUMKA (ORCPT ); Wed, 21 Jan 2009 07:10:00 -0500 Content-Disposition: inline In-Reply-To: <20090121114122.GS24891@wotan.suse.de> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Nick Piggin wrote: > Well, given that postgresql post that they need to sync multiple > files, I think fsyncv is a nice way forward. It can be used to > implement fsync_range too, which is slightly portable. Also, fsyncv on multiple files could issue just the one disk cache flush, if they're all to the same disk... [about sync_file_range] > If the queue fills up it has to block. It cannot schedule a thread > to write out asynchronously, etc. Because userspace is directing > how the implementation should work rather than the high level > intention. I agree that it's overly constraining, and pushes unnecessary tuning work into userspace. All these calls, btw, would be much more "optimisable" in the kernel if they were AIOs. Let the kernel decide things like how much to batch, how much to parallelise, and still have the hint which comes from AIO submission order (userspace threads doing synchronous I/O loses this bit). But that doesn't seem likely to happen because it's really quite hard. -- Jamie