Journaling layer update - any really good programmer want to start working on the userland journal scanning utility ? You need to have a LOT of time available!

Miguel Mendez flynn at energyhq.es.eu.org
Mon Mar 7 12:37:43 PST 2005


On Fri, 4 Mar 2005 13:36:34 -0800 (PST)
Matthew Dillon <dillon at xxxxxxxxxxxxxxxxxxxx> wrote:


>     The way the UNDO works is that the journal is made 'reversable', meaning
>     that you can run the journal forwards and execute the related filesystem
>     operations in order to 'track' a filesystem, or you can run the journal
>     backwards in order to reverse-time-index a filesystem.  So what you get
>     is an infinitely fine-grained undo capability.

That was quick Matt :) I've seen you've committed jscan already. So,
some new questions pop up :)
 
As per the mountctl page, I've added a journal to /. However, in my
first try I did mountctl -a -w /.journal1 /:journal1. Then, bad things
happened. Putting the journal in /usr works fine. Perhaps the man page
should warn about this, as obvious as it might seem.

Now jscan. I've taken a brief look at the code and it seems to work
only with either stdin or a regular file. I've been studying the
journaling code this afternoon and was thinking how the jscan program
was supposed to access the journaling data. So the question is, what do
you think about providing an ioctl call that would give access to the
journaling data, rather than having to provide a file? I'm aware of the
fact that jscan is far from finished, so are you going to provide a
more general way to access the data? If I understood it right,
journaling data could live anywhere, maybe even on another node over
the network. If that's correct some sort of URI would be needed in
order to be able to use jscan when the log data is not in a file. Or,
as I've said, provide a mechanism to allow jscan to access the data,
via ioctl or another way. What do you think?

Cheers,
-- 
Miguel Mendez <flynn at xxxxxxxxxxxxxxxxxx>
http://www.energyhq.es.eu.org
PGP Key: 0xDC8514F1

Attachment:
pgp00001.pgp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00001.pgp
Type: application/octet-stream
Size: 187 bytes
Desc: "Description: PGP signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20050307/baa78d9f/attachment-0018.obj>


More information about the Kernel mailing list