Re: 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!

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:
:That was quick Matt :) I've seen you've committed jscan already. So,
:some new questions pop up :)
:=20
: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.

    Ho!  I thought of this, and the question is whether to add a flag to
    the vnode to prevent the journaling code from journaling the journaling
    file itself, or whether to try to warn about the circular loop and
    refuse to allow it.  I can see some situations where you might want
    to backup a filesystem holding live journaling files so the main issue
    is how to detect the circular loop.

: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,
:--=20
:Miguel Mendez <flynn@xxxxxxxxxxxxxxxxxx>

    I'm not sure what you mean by 'ioctl'.  The journaling stream is 
    basically just data.  jscan is far from done, but the idea is for
    forward scans to be able to operate over a pipe, whereas reverse scans
    require a working lseek().  jscan doesn't handle forward scans over a
    pipe yet (it still tries to seek if it gets out of sync).  I've
    abstracted out the code, however, and will soon fix that.  

    So far jscan is able to resynchronize the stream, collect transaction
    records together, and iterate through the subrecord hierarchy.

    Soon jscan will be able to do filesystem mirroring, shell command
    equivalent output, undo, and a bunch of other things.  I hope to have 
    the actual mirroring functionality working by the end of the week.

    On the OS side I still need to implement the transaction id 
    acknowledgement feature and the swap-backed feature so pipe interruptions
    (someone ^C's the jscan on the target or the TCP connection is broken)
    do not create gaps in the journal.  And I also need to implement the UNDO
    dataset generation and clean up a bunch of other things.

    But I'm very happy with the overall progress being made on the thing.
    When the code is working well enough to actually do backups, I'll make
    another announcement.

						-Matt