| From: | Miguel Mendez <flynn@xxxxxxxxxxxxxxxxxx> |
| Date: | Mon, 7 Mar 2005 21:33:25 +0100 |
On Fri, 4 Mar 2005 13:36:34 -0800 (PST) Matthew Dillon <dillon@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@xxxxxxxxxxxxxxxxxx> http://www.energyhq.es.eu.org PGP Key: 0xDC8514F1
Attachment:
pgp00001.pgp
Description: PGP signature