From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 7 21:26:00 2005 Return-Path: X-Original-To: hackers@FreeBSD.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC78716A41C; Tue, 7 Jun 2005 21:26:00 +0000 (GMT) (envelope-from dwmalone@maths.tcd.ie) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id BC54343D48; Tue, 7 Jun 2005 21:25:59 +0000 (GMT) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie ([134.226.81.10] helo=maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 7 Jun 2005 22:25:58 +0100 (BST) To: Scott Long In-reply-to: Your message of "Tue, 07 Jun 2005 14:52:44 MDT." <42A6091C.40409@samsco.org> X-Request-Do: Date: Tue, 07 Jun 2005 22:25:58 +0100 From: David Malone Message-ID: <200506072225.aa16681@salmon.maths.tcd.ie> Cc: scottl@FreeBSD.org, hackers@FreeBSD.org, Pawel Jakub Dawidek , phk@FreeBSD.org, Ivan Voras Subject: Re: Google SoC idea X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2005 21:26:01 -0000 > The problem with journalling at the block layer is that you pretty much > become forced to journal metadata and data, since the block layer really > doesn't know the distinction, Definitely - I guess I should have stated that explicitly. > Full journalling has many drawbacks from the viewpoint of > speed and complexity, of course. So you really want to be able to do > just metadata journalling. The complexity of full journaling (for filesystems that offer a consistent version of themselves to the disk layer) would not seem to be that high: a scheme like Ivan's seems to achieve it. Maybe I've missed something? For us, journaling the metadata is of interest because we're interested in avoiding fscks. I suppose full journaling may be of interest to people with other applications, despite the unfortunate performance in many situations. > An alternate SoC project that would be very useful is block-level > snapshots. I'm not sure if I'll be able to retain the filesystem > snapshot functionality in UFS with journalling enabled, so moving to > doing the snapshots in the block layer would be a good way to make up > for this. Beware that while the GEOM transform would be pretty > straight-forward to write, the real trick comes from being able to make > the consumer of a block device (a filesystem, maybe) flush itself to a > consistent state while the snapshot is being taken. The infrastructure > for this is the part that is very interesting, but also the most work. Definitely another interesting project, though maybe a bit too much work to ask someone to do for $4500 over a summer... David.