From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jamie Lokier Subject: Re: barriers vs. reads Date: Tue, 22 Jun 2004 20:57:46 +0100 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <20040622195746.GB24771@mail.shareable.org> References: <20040622005302.A1325@almesberger.net> <20040622073919.GV12881@suse.de> <20040622045004.C1325@almesberger.net> <20040622075531.GX12881@suse.de> <20040622112802.GA21456@mail.shareable.org> <20040622113245.GA1104@suse.de> <20040622155308.G1325@almesberger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jens Axboe , linux-fsdevel@vger.kernel.org Return-path: Received: from mail.shareable.org ([81.29.64.88]:22697 "EHLO mail.shareable.org") by vger.kernel.org with ESMTP id S265132AbUFVT5y (ORCPT ); Tue, 22 Jun 2004 15:57:54 -0400 To: Werner Almesberger Content-Disposition: inline In-Reply-To: <20040622155308.G1325@almesberger.net> List-Id: linux-fsdevel.vger.kernel.org Werner Almesberger wrote: > (For partially overlapping requests, it may actually be nice > to be able to break them into multiple parts, and queue them > separately. Particularly if they also come with distinct > priorities.) If there's a read which depends on a prior write, doesn't it make more sense to just copy the data in memory for the parts which overlap? If you do that, then you can service all high priority reads properly: those that don't overlap can cross write barriers, and those that do overlap can be copied in memory immediately. There may be a case for forcing a direct read for programs which check storage data integrity, although probably not even then is it useful. (A program that wants to write some data and then read using direct I/O will call write(), _wait_ until that returns after committing the data, and then call read()). Even if the current behaviour of requiring a device read after the barrier must remain for ordinary direct I/O, it isn't required for requests marked as "high-priority I/O". -- Jamie