Date: Wed, 08 Jun 2005 08:21:56 -0600 From: Scott Long <scottl@samsco.org> To: Ivan Voras <ivoras@fer.hr> Cc: David Malone <dwmalone@maths.tcd.ie>, scottl@FreeBSD.org, hackers@FreeBSD.org, Pawel Jakub Dawidek <pjd@FreeBSD.org>, phk@FreeBSD.org Subject: Re: Google SoC idea Message-ID: <42A6FF04.706@samsco.org> In-Reply-To: <42A6C311.5090400@fer.hr> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42A6FF04.706>