From mboxrd@z Thu Jan 1 00:00:00 1970 From: Werner Almesberger Subject: Re: barriers vs. reads - O_DIRECT Date: Thu, 24 Jun 2004 17:55:16 -0300 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <20040624175516.W1325@almesberger.net> References: <20040623214845.A21586@almesberger.net> <20040624144638.V1325@almesberger.net> <20040624185059.GA11175@mail.shareable.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Bryan Henderson , linux-fsdevel@vger.kernel.org Return-path: Received: from almesberger.net ([63.105.73.238]:62725 "EHLO host.almesberger.net") by vger.kernel.org with ESMTP id S265548AbUFXUzf (ORCPT ); Thu, 24 Jun 2004 16:55:35 -0400 To: Jamie Lokier Content-Disposition: inline In-Reply-To: <20040624185059.GA11175@mail.shareable.org>; from jamie@shareable.org on Thu, Jun 24, 2004 at 07:50:59PM +0100 List-Id: linux-fsdevel.vger.kernel.org Jamie Lokier wrote: > Note that what filesystems and databases want is write-write *partial > dependencies*. The per-device I/O barrier is just a crude > approximation. True ;-) So what would an ideally flexible model look like ? Partial order ? Triggers plus virtual requests ? There's also the little issue that this should still yield an interface that people can understand without taking a semester of graph theory ;-) > 3. What if a journal is on a different device to its filesystem? "Don't do this" comes to mind :-) > Isn't the barrier itself an I/O operation which can be waited on? > I agree something could depend on the reads at the moment. Making barriers waitable might be very useful, yes. That could also be a step towards implementing those cross-device barriers. - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://www.almesberger.net/____________________________________________/