Re: newbie question

["K. Richard Pixley" <rich-pBcMlXao8V4@public.gmane.org>]

Jiro SEKIBA wrote:
 > Hi, Richard
 >
 > At Thu, 27 May 2010 10:40:41 -0700,
 > K. Richard Pixley wrote:
 >
 >> Ryusuke Konishi wrote:
 >>
 >>> The "roll back" feature is one of our todo items, and not yet
 >>> supported.
 >>>
 >> Is this something that could be accelerated by a suitable 
application of
 >> money?
 >>
 >
 > I may not understand your question, but technically speaking
 > it is possible to support roll back feature.
 > It's just a matter of work force to do as far as I think.
 >
 > Still, there are some concerns about what the "roll back" sould be.
 >
 > For instance, if you just want to restore from a specific snapshot 
you took,
 > you can simply read-only mount the snapshot and copy the contents you
 > want to restore.  That is done without any filesystem level roll back 
support.
 >

Yes, but the copying requires a significant amount of time that I'm 
trying to avoid.

I start with a known good file system.  I snapshot it.  I take some 
speculative action.  And then, based on the result of the speculative 
action, I either want to create a new snapshot and continue on from 
there, or I want to "roll back" to the snapshot as though the 
speculative action had never taken place.

Effectively, I want to start with known good data and then "try 
something".  If the trial succeeds, then I have a new good state.  But 
if it fails, then my entire sub tree is polluted and needs to be 
replaced or rolled back before I can try something else.

This is akin to a parser with 1 item lookahead or to an AI search tree 
of depth 1.  That is, I'm looking for a cheap backtracking mechanism.

My first strategy involved rsync'ing a subtree elsewhere in the file 
system as my snapshotting mechanism and then using rsync to replace my 
current subtree when I needed to "roll back".  This costs two large 
copies and the copies take as much or more time than my transforms do. 
This means that the copies are the most expensive thing my system does.

My second strategy has been to use LVM snapshots.  The cost of rolling 
back is effectively zero, but I have a small problem in that snapshots 
can't be snapshotted, (that is, no recursion).  Instead, when the 
speculative action is successful, I either need to copy the successful 
data back to the original device or I need to repeat the speculative 
action on the original device, either of which are slow operations 
comparable to copying my entire subtree again.

What I really want is the ability to make a snapshot, take my 
speculative action, and then pick which one I want to keep moving 
forward, without needing to copy all of the data.

If I'm understanding nilfs2 semantics, then it's trivial to discard the 
snapshot but discarding the most recent state of the file system 
requires a long copy in user space.  I would expect that "roll back" 
would allow me to simply discard everything that has happened in the 
file system after a particular snapshot, (permanently and with no 
mechanism for recovery), returning the file system to that snapshot's 
state with read-write ability, and would do so significantly faster than 
copying my entire file system.

 > Or you want to undone what you did in filesystem, you may be able to
 > delete log and set proper super block.  That is tricky, but possible
 > without filesystem level support if it's not mounted.

It this is true, then I'd like to see it in one of the utility programs.

 > The hard one is live "roll back", I think, which undone the things on
 > mounted filesystem, or maybe at the boot time by specifying a checkpoint.

For my application, it would be sufficient to "roll back" while the 
system was unmounted, or to somehow mark the portions to be discarded 
and then remount at the checkpoint I want to keep.

 > In any cases, there should be some utility programs to achieve the
 > functionalities above even it doesn't require any filesystem 
modifications.

It seems to me that there's not really any conflict about what might be 
provided, but more a question of the degree to which guarantees are kept 
during the process.

"Rolling back" is a clearly desirable feature.  The declarations should 
be made using one of the utility programs.  Doing so on an unmounted 
file system is a win over not doing it at all.  And doing it on a 
mounted file system is a win over doing it on an unmounted file system.

--rich
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html