Journaling UFS with gjournal.

[Pawel Jakub Dawidek]

On Mon, Jun 19, 2006 at 08:37:29AM -0700, R. B. Riddick wrote:
+> --- Pawel Jakub Dawidek <pjd at FreeBSD.org> wrote:
+> > On Mon, Jun 19, 2006 at 06:37:06AM -0700, R. B. Riddick wrote:
+> > +> --- Pawel Jakub Dawidek <pjd at FreeBSD.org> wrote:
+> > +> > 2. If we have file system, synchronize it.
+> > +> > 3. Mark file system as clean.
+> > +> > 4. Block all write requests to the file system.
+> > +> >
+> > +> Shouldn't we do 4. before 2.?
+> > 
+> > 4 is done via vfs_write_suspend() function, which synchronize file
+> > system once again.
+> >
+> OK. Does vfs_write_suspend mark the file system as clean again, too?
+> I mean: What if bewteen step 3 and 4 someone makes the file system dirty?

The order of those points isn't really exact. It was more to illustrate
what's going on in there. The order in the code is correct. The file
system is marked as clean when there cannot be more write requests and
when file system is fully synchronized.

+> > As I said gjournal is below file system layer. It receives I/O requests
+> > only and cannot say which one is related to growing file, which has
+> > metadata inside, etc.
+> > 
+> Yeah, below -- as u said in the email, I responded to...
+> I thought, the file system code supports gjournal somehow in that point, too...
+> And I was too lazy to look into the patch u provided...
+> 
+> Might it be possible to get some more optional assistance by the file system?
+> Maybe we could provide a /dev/ad0.gjournal and a /dev/ad0.fs-data, which would
+> break the GEOM concept a little bit...? *sigh*
+> Maybe the file system code could use negative block numbers or high block
+> numbers (somehow like a hint: U can write it right to the file system without
+> any worries)?
+> Of course those quick-write-through blocks should not be subject to a remove
+> operation in the currently active journal area (I mean just in case, the system
+> crashes while that journal is still active)...

It's quite complex and not really nice to store such informations inside
bio structure, but I hope current gjournal is only a start, there is a
lot of room for improvements. For example synchronizing file system
isn't cheap, but before gjournal its speed wasn't really important, now
it is more important, and speeding it up will speed up gjournal.

-- 
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-fs/attachments/20060619/baa6f29c/attachment.pgp