From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 8 14:23:15 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 0310416A41C; Wed, 8 Jun 2005 14:23:15 +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 8613543D49; Wed, 8 Jun 2005 14:23:14 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [10.0.2.2] ([12.174.84.3]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j58ESm2c067534; Wed, 8 Jun 2005 08:28:52 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42A6FF04.706@samsco.org> Date: Wed, 08 Jun 2005 08:21:56 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ivan Voras References: <42A475AB.6020808@fer.hr> <20050607194005.GG837@darkness.comp.waw.pl> <20050607201642.GA58346@walton.maths.tcd.ie> <42A6091C.40409@samsco.org> <42A6C311.5090400@fer.hr> In-Reply-To: <42A6C311.5090400@fer.hr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=3.8 tests=none autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: David Malone , scottl@FreeBSD.org, hackers@FreeBSD.org, Pawel Jakub Dawidek , phk@FreeBSD.org 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: Wed, 08 Jun 2005 14:23:15 -0000 Ivan Voras wrote: > Scott Long wrote: > >> 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 > > > One addenum that was introduced after I made the post to hackers@, but > before sending a proposal to Google (PHK's idea, actually) is to > implement a delayed-commit mode, in which journaled data will not be > commited until requested. > > This would allow something like block-level snapshots, but one-shot only > (or at least one per journal). Again, I'm not exactly sure how a generic mechanism can handle the distinction of data vs. metadata vs. journal data. Also, what you need to delay is not the journal writes, but the metdata writes. In order for journal replay to work, the on-disk journal must always be ahead of the on-disk metadata, and the proper bookkeeping must be kept to track what sectors have been committed to the drive and what sectors haven't. Again, you simply don't get this 'for free'. Scott