From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751774AbbCNGYH (ORCPT ); Sat, 14 Mar 2015 02:24:07 -0400 Received: from cantor2.suse.de ([195.135.220.15]:37483 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750841AbbCNGYD (ORCPT ); Sat, 14 Mar 2015 02:24:03 -0400 Date: Sat, 14 Mar 2015 07:23:56 +0100 From: Jan Kara To: "Leonid V. Fedorenchik" Cc: Jonathan Corbet , Mike Christie , "Martin K. Petersen" , Jens Axboe , Hannes Reinecke , Jan Kara , Christoph Hellwig , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] Documentation: Remove mentioning of block barriers Message-ID: <20150314062356.GA2096@quack.suse.cz> References: <1426280002-11940-1-git-send-email-leonidsbox@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1426280002-11940-1-git-send-email-leonidsbox@gmail.com> 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 On Fri 13-03-15 23:53:22, Leonid V. Fedorenchik wrote: > Remove mentioning of block barriers since they were removed. > > Signed-off-by: Leonid V. Fedorenchik The change looks fine. It would be nice to at least reference Documentation/block/writeback_cache_control.txt for description of REQ_FLUSH and REQ_FUA flags. Honza > --- > Documentation/block/biodoc.txt | 36 +++++++++--------------------------- > 1 file changed, 9 insertions(+), 27 deletions(-) > > diff --git a/Documentation/block/biodoc.txt b/Documentation/block/biodoc.txt > index 5aabc08..fd12c0d 100644 > --- a/Documentation/block/biodoc.txt > +++ b/Documentation/block/biodoc.txt > @@ -48,8 +48,7 @@ Description of Contents: > - Highmem I/O support > - I/O scheduler modularization > 1.2 Tuning based on high level requirements/capabilities > - 1.2.1 I/O Barriers > - 1.2.2 Request Priority/Latency > + 1.2.1 Request Priority/Latency > 1.3 Direct access/bypass to lower layers for diagnostics and special > device operations > 1.3.1 Pre-built commands > @@ -255,29 +254,12 @@ some control over i/o ordering. > What kind of support exists at the generic block layer for this ? > > The flags and rw fields in the bio structure can be used for some tuning > -from above e.g indicating that an i/o is just a readahead request, or for > -marking barrier requests (discussed next), or priority settings (currently > -unused). As far as user applications are concerned they would need an > -additional mechanism either via open flags or ioctls, or some other upper > -level mechanism to communicate such settings to block. > - > -1.2.1 I/O Barriers > - > -There is a way to enforce strict ordering for i/os through barriers. > -All requests before a barrier point must be serviced before the barrier > -request and any other requests arriving after the barrier will not be > -serviced until after the barrier has completed. This is useful for higher > -level control on write ordering, e.g flushing a log of committed updates > -to disk before the corresponding updates themselves. > - > -A flag in the bio structure, BIO_BARRIER is used to identify a barrier i/o. > -The generic i/o scheduler would make sure that it places the barrier request and > -all other requests coming after it after all the previous requests in the > -queue. Barriers may be implemented in different ways depending on the > -driver. For more details regarding I/O barriers, please read barrier.txt > -in this directory. > - > -1.2.2 Request Priority/Latency > +from above e.g indicating that an i/o is just a readahead request, or priority > +settings (currently unused). As far as user applications are concerned they > +would need an additional mechanism either via open flags or ioctls, or some > +other upper level mechanism to communicate such settings to block. > + > +1.2.1 Request Priority/Latency > > Todo/Under discussion: > Arjan's proposed request priority scheme allows higher levels some broad > @@ -906,8 +888,8 @@ queue and specific I/O schedulers. Unless stated otherwise, elevator is used > to refer to both parts and I/O scheduler to specific I/O schedulers. > > Block layer implements generic dispatch queue in block/*.c. > -The generic dispatch queue is responsible for properly ordering barrier > -requests, requeueing, handling non-fs requests and all other subtleties. > +The generic dispatch queue is responsible for requeueing, handling non-fs > +requests and all other subtleties. > > Specific I/O schedulers are responsible for ordering normal filesystem > requests. They can also choose to delay certain requests to improve > -- > 2.2.1 > -- Jan Kara SUSE Labs, CR