Journaling UFS with gjournal.

[Pawel Jakub Dawidek]

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.
+> 
+> > 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.
+> 
+> Some random comments:
+> 
+> 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.

-- 
Pawel Jakub Dawidek                       http://www.wheel.pl
pjd at FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20060622/885b518f/attachment.pgp