Re: Journaling layer update - any really good programmer want to
:
: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@energyhq.es.eu.org>
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
討論串 (同標題文章)
完整討論串 (本文為第 5 之 12 篇)：