From owner-freebsd-geom@FreeBSD.ORG Sun Apr 22 03:30:45 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D116516A400 for ; Sun, 22 Apr 2007 03:30:45 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from mh1.centtech.com (moat3.centtech.com [64.129.166.50]) by mx1.freebsd.org (Postfix) with ESMTP id A622613C455 for ; Sun, 22 Apr 2007 03:30:45 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from neutrino.centtech.com (andersonbox1.centtech.com [192.168.42.21]) by mh1.centtech.com (8.13.8/8.13.8) with ESMTP id l3M3UYn5038039; Sat, 21 Apr 2007 22:30:37 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <462AD6DA.1070203@freebsd.org> Date: Sat, 21 Apr 2007 22:30:34 -0500 From: Eric Anderson User-Agent: Thunderbird 2.0.0.0 (X11/20070420) MIME-Version: 1.0 To: Ivan Voras References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.4/3146/Sat Apr 21 14:39:19 2007 on mh1.centtech.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=8.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on mh1.centtech.com Cc: freebsd-geom@freebsd.org Subject: Re: gjournal & async X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2007 03:30:45 -0000 On 04/21/07 19:43, Ivan Voras wrote: > How does gjournal guarantee corectness if UFS is mounted async? AFAIK > the "async" handling of IO requests is done by the UFS, the writes are > not rescheduled at the GEOM layer? > I'm slightly guessing here that it can guarantee consistency because async writes may not have made it to the disk (the journal), and when gjournal replays the journal, it syncs the file system (flushing all the writes to disk first), then writes the journaled data to the consistent file system image. So, a write that is claimed as 'completed' to the process by the kernel, may still be in memory, and only partially written to the journal, or not at all. Either way, if an unclean unmount of the filesystem occurs, it's either lost completely, a partial journal write (so should be tossed anyway), or a complete journal entry synced down just before journal switch. Eric