From owner-freebsd-fs@FreeBSD.ORG Mon Mar 23 21:31:30 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04955106568E for ; Mon, 23 Mar 2009 21:31:30 +0000 (UTC) (envelope-from mel.flynn+fbsd.fs@mailing.thruhere.net) Received: from mailhub.rachie.is-a-geek.net (rachie.is-a-geek.net [66.230.99.27]) by mx1.freebsd.org (Postfix) with ESMTP id A23A88FC0C for ; Mon, 23 Mar 2009 21:31:28 +0000 (UTC) (envelope-from mel.flynn+fbsd.fs@mailing.thruhere.net) Received: from sarevok.dnr.servegame.org (gate.lan.rachie.is-a-geek.net [192.168.2.10]) by mailhub.rachie.is-a-geek.net (Postfix) with ESMTP id 86C947E81A; Mon, 23 Mar 2009 13:31:27 -0800 (AKDT) From: Mel Flynn To: freebsd-fs@freebsd.org Date: Mon, 23 Mar 2009 22:31:26 +0100 User-Agent: KMail/1.11.0 (FreeBSD/8.0-CURRENT; KDE/4.2.0; i386; ; ) References: <200903231733.51671.mel.flynn+fbsd.fs@mailing.thruhere.net> <49C7C45B.7040708@elischer.org> In-Reply-To: <49C7C45B.7040708@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903232231.26279.mel.flynn+fbsd.fs@mailing.thruhere.net> Cc: Julian Elischer Subject: Re: Trying to understand how aio(4), mount(8) async (and gjournal) relate X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 21:31:30 -0000 On Monday 23 March 2009 18:18:19 Julian Elischer wrote: > Mel Flynn wrote: > > Hello list, > > > > in an effort to try and understand the various async systems available, > > it's unclear to me how (if at all) the above relate. > > > > If one mounts a disk with async, does this internally use aio system > > calls, or is there a subsystem available which does largely the same? If > > so, why are there 2 subsystems? > > the async mount operation tells the systewm that writes done by a > process may be actually written to teh filesystem at any time later, > and that it is ok to return "success" to the user immediately, > regardless of whether the write has actually been done. > This also applies to the metadata. It does not affect reads at all. So it is up to the underlying geom provider to handle the write queue? > > > When using aio, for example with squid, does this mean the underlying > > provider needs to be mounted async or is this totally unrelated? > > Similarly if said disk is on a gjournalled partition, is the async mount > > redundant or is using aio redundant or neither? > > no the aio system calls are implemented in a manner that allows > the caller to request IO and then return at a later time to find out > the result. it has no connection to the mount option. So with aio_write(2) on an async gjournal fs, one faces a write queue on the fd used by aio(4) along with another made by gjournal? This leads me to believe that it's better to take one of those out of the equation for performance. > BTW for efficient async IO check out the relationship between the aio > calls and the kqueue calls. Thanks for the pointer, reading up ... -- Mel