Date: Thu, 22 Jun 2006 12:06:14 +0200 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: Bakul Shah <bakul@bitblocks.com> Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-geom@FreeBSD.org Subject: Re: Journaling UFS with gjournal. Message-ID: <20060622100614.GF30568@garage.freebsd.pl> In-Reply-To: <20060620202948.933F2294C1@mail.bitblocks.com> References: <20060619131101.GD1130@garage.freebsd.pl> <20060620202948.933F2294C1@mail.bitblocks.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--VuQYccsttdhdIfIP Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 20, 2006 at 01:29:48PM -0700, Bakul Shah wrote: +> This is great! We have sorely needed this for quite a while +> what with terabyte size filesystems getting into common use. +>=20 +> > How it works (in short). You may define one or two providers which +> > gjournal will use. If one provider is given, it will be used for both - +> > data and journal. If two providers are given, one will be used for data +> > and one for journal. +> > Every few seconds (you may define how many) journal is terminated and +> > marked as consistent and gjournal starts to copy data from it to the +> > data provider. In the same time new data are stored in new journal. +>=20 +> Some random comments: +>=20 +> Would it make sense to treat the journal as a circular +> buffer? Then commit to the underlying provider starts when +> the buffer has $hiwater blocks or the upper layer wants to +> sync. The commit stops when the buffer has $lowater blocks +> or in case of sync the buffer is empty. This will allow +> parallel writes to the provider and the journal, thereby +> reducing latency. This is bascially what is done now. There are always two journal - active and inactive. New data are written to the active journal. When journal switch time arrives (timeout occurs or cache is full), the active journal is terminated and new active journal is started right after this one. The previous active journal becomes inactive and the data is copied to the destination (data) provider in parallel to new requests which are stored in the active journal. Writes are suspended only on synchronize file system and terminate the active journal. Copying data from the inactive journal is done in parallel to normal operations. +> I don't understand why you need FS synchronization. Once the +> journal is written, the data is safe. [...] Which data? When you for example delete a file, you need to perform those operations: - remove name from a directory - mark inode as free - mark blocks as free Synchronizing file system gives me certainty that all those operations reached gjournal, so I can safely mark file system as clean and terminate the journal. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --VuQYccsttdhdIfIP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFEmmuWForvXbEpPzQRAkx5AKDwCF5E7AnzKAMcIrzidCm3f841GACfbc4W TbyLYq/4XoccF4Zb4qfRNac= =OMuu -----END PGP SIGNATURE----- --VuQYccsttdhdIfIP--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060622100614.GF30568>