From owner-freebsd-current@FreeBSD.ORG Tue Jul 26 15:34:07 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1173416A41F for ; Tue, 26 Jul 2005 15:34:07 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4140743D49 for ; Tue, 26 Jul 2005 15:34:06 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j6QFhPwm096214; Tue, 26 Jul 2005 09:43:25 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42E657DA.3010102@samsco.org> Date: Tue, 26 Jul 2005 09:33:46 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Luigi Rizzo References: <20050726065444.A37735@xorpc.icir.org> In-Reply-To: <20050726065444.A37735@xorpc.icir.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: s223560@studenti.ing.unipi.it, current@freebsd.org Subject: Re: multiple pending filesystem requests for the same block ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2005 15:34:07 -0000 Luigi Rizzo wrote: > (context: SoC work on pluggable disk schedulers, > http://wikitest.freebsd.org/moin.cgi/Hybrid > > > The doubt we have is the following: > > can the filesystem code have multiple pending write requests for > the same disk block ? > > the current (elevator) disk scheduler should have no problem with > this, because even if disksort reorders requests, two requests > for the same block retain the issue ordering. > > However we wonder if this feature is actually expected by > the filesystem code, or it does not matter because it > never issues a new request before the previous one on the > same area is complete. > > thanks > luigi A write can either be direct through a strategy routine (and bypass the bufcache), or it can be synchronous via bwrite(), or it can be asynchronous via bawrite() and bdwrite(). For the synchronous cases there is no guarantee of ordering. For the async case (which most writes in the FS are), the bufcache will coelsce multiple writes to the same block. Softupdate intercepts metadata writes and ensures that they get coelesced and ordered correctly. Data writes happen on a first come first serve basis, and it's up to the application to use file locks to ensure proper ordering between competing processes or threads. Scott