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]

On Mon, 7 Mar 2005 12:52:09 -0800 (PST)
Matthew Dillon <dillon at xxxxxxxxxxxxxxxxxxxx> wrote:


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

IMHO in some cases the user may want to have the log data on the same
filesystem being logged, so it would be useful if the system could
detect that this file's ops are not to be logged.

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

Now that I think about it, it wouldn't be that useful. Let's say I do
mountctl -a -w /journals/.journal1 /:journal1 . Then the box crashes
but I keep my journals on a e.g. NFS server, so it's not a problem to
get them. I tell jscan to read said journal and replay the missing
transactions. What I was thinking about was having jscan ask the kernel
for the path to the streamable data automagically, rather than have the
user specify it. So jscan could issue an ioctl call, or get the info
via sysctl saying "log file for filesystem $FS is $FILE".

Since journals aren't persistant across reboots, this would be of
limited use now. So, what are you going to do about that? Having some
kind of /etc/rc.d/journal script that will mountctl the partitions,
perhaps reading the data from e.g. /etc/mountctl.conf, or are you going
to store the journal info in the filesystem, perhaps in the superblock?

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

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

Great, can't wait for it :)

Cheers,
-- 
Miguel Mendez <flynn at xxxxxxxxxxxxxxxxxx>
http://www.energyhq.es.eu.org
PGP Key: 0xDC8514F1
Attachment:
pgp00002.pgp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00002.pgp
Type: application/octet-stream
Size: 187 bytes
Desc: "Description: PGP signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20050307/38110f99/attachment-0020.obj>