From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jamie Lokier Subject: Re: barriers vs. reads Date: Thu, 24 Jun 2004 14:43:07 +0100 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <20040624134307.GB8440@mail.shareable.org> References: <20040622205309.GC3200@suse.de> <20040623165351.GE32544@mail.shareable.org> <20040623202304.O1325@almesberger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Bryan Henderson , Jens Axboe , linux-fsdevel@vger.kernel.org Return-path: Received: from mail.shareable.org ([81.29.64.88]:20394 "EHLO mail.shareable.org") by vger.kernel.org with ESMTP id S264686AbUFXNpG (ORCPT ); Thu, 24 Jun 2004 09:45:06 -0400 To: Werner Almesberger Content-Disposition: inline In-Reply-To: <20040623202304.O1325@almesberger.net> List-Id: linux-fsdevel.vger.kernel.org Werner Almesberger wrote: > i) write requests may never cross a barrier that separates > them from other write requests > ii) a read request R and a write request W may change their > order (with respect to each other), unless they overlap > AND are separated by at least one barrier > iii) in all other cases, requests are free to move about > > Rule ii) seems a little tricky. Is there actually a means for > user space to send a barrier, e.g. when doing direct IO ? If > not, the I think only user of ii) would be "direct IO" that > comes from unbuffered file system meta-data and such. It should be possible to write a decent filesystem in userspace -- even if it's just for prototyping -- so barriers from userspace should be offered, eventually. Note that unbuffered file system meta-data can theoretically overlap page cache, although it usually doesn't, and a filesystem could easily set a flag to say that it doesn't ever. Think of the experimental modifications to ext3 to allow inodes to be allocated in a file. That means blocks are changing their meaning from being file blocks to inode blocks or vice versa -- and both I/Os could conceivably be in flight at the same time. -- Jamie