Journaling UFS with gjournal.

[Oliver Fromme]

Pawel Jakub Dawidek <pjd at freebsd.org> wrote:
 > GJournal was designed to journal GEOM providers, so it actually works
 > below file system layer, but it has hooks which allow to work with
 > file systems. In other words, gjournal is not file system-depended,
 > it can work probably with any file system with minimum knowledge
 > about it. I implemented only UFS support.

Very cool.  Thanks for providing journaling to FreeBSD.

How "stable" should your code be considered?  I assume it
hasn't been subject to testing by a wider audience yet,
so it should be considered "alpha" quality, right?

I have a few questions ...

First of all, is it possible to add journaling to an
existing file system, i.e. without having to dump, newfs
and restore?

 > 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.

In the case of only one provider given, how is the size of
the journal specified?

 > When last
 > name is deleted, the file/directory is moved to the .deleted/
 > directory and removed from there on last close.

Is that directory located in the root of the file system,
similar to the .snap directory for snapshots?

(It reminds me of the similar case when files are deleted
from an NFS server.  If they're still held open by processes,
they get renamed to .nfsXXXX within the original directory.
I wish they would be moved into a fixed directory instead,
too.)

 > [...]
 > Reading. grep -r on two src/ directories in parallel:
 > UFS:            84s
 > UFS+SU:         138s
 > gjournal(1):    102s
 > gjournal(2):    89s
 > 
 > As you can see, even on one disk, untaring eight src.tgz is two times
 > faster than UFS+SU. I've no idea why gjournal is faster in reading.

Maybe it is because of the atime updates.  You'll get a lot
of them when grepping recursively on the src tree.

Best regards
   Oliver

-- 
Oliver Fromme,  secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.

"Clear perl code is better than unclear awk code; but NOTHING
comes close to unclear perl code"  (taken from comp.lang.awk FAQ)