newbie question

newbie question

[Rich Pixley]

Can nilfs "roll back" to a previous state of the file system?

For example, at some time = T(N), I have a file system in a known good 
state.  So I check point it before taking a risky action.  Then I take a 
risky action which leads me to the file system state at T(N+1).

Sometimes, my risky action will be fine and I'll want to continue on.  
Other times, my risky action will result in a polluted, useless 
collection of data which I would like to discard.

I understand that at time T(N+1) nilfs will allow me to create a 
checkpoint of T(N) which can be mounted read-only.  What I'm asking is 
if nilfs can discard the state at T(N+1) and "roll back" to the state at 
T(N) as though T(N+1) had never happened.

Can nilfs do this kind of "roll back"?

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

Re: newbie question

[Jérôme Poulin]

Sorry to say, but this is the first point in the TODO List:
Checkpoint rollback
See http://www.nilfs.org/en/current_status.html

However, I wonder if this has been worked on being the first point, I
guess it should not be hard to do, isn't that what NILFS does on boot
after an unclean shutdown?


On Thu, May 20, 2010 at 5:17 PM, Rich Pixley <rich.pixley-C65YXLrEp3M@public.gmane.org> wrote:
>
> Can nilfs "roll back" to a previous state of the file system?
>
> For example, at some time = T(N), I have a file system in a known good state.  So I check point it before taking a risky action.  Then I take a risky action which leads me to the file system state at T(N+1).
>
> Sometimes, my risky action will be fine and I'll want to continue on.  Other times, my risky action will result in a polluted, useless collection of data which I would like to discard.
>
> I understand that at time T(N+1) nilfs will allow me to create a checkpoint of T(N) which can be mounted read-only.  What I'm asking is if nilfs can discard the state at T(N+1) and "roll back" to the state at T(N) as though T(N+1) had never happened.
>
> Can nilfs do this kind of "roll back"?
>
> --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
--
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

Re: newbie question

[Ryusuke Konishi]

Hi,
On Thu, 20 May 2010 14:17:20 -0700, Rich Pixley wrote:
> Can nilfs "roll back" to a previous state of the file system?
> 
> For example, at some time = T(N), I have a file system in a known good 
> state.  So I check point it before taking a risky action.  Then I take a 
> risky action which leads me to the file system state at T(N+1).
> 
> Sometimes, my risky action will be fine and I'll want to continue on.  
> Other times, my risky action will result in a polluted, useless 
> collection of data which I would like to discard.
> 
> I understand that at time T(N+1) nilfs will allow me to create a 
> checkpoint of T(N) which can be mounted read-only.  What I'm asking is 
> if nilfs can discard the state at T(N+1) and "roll back" to the state at 
> T(N) as though T(N+1) had never happened.
> 
> Can nilfs do this kind of "roll back"?
> 
> --rich

The "roll back" feature is one of our todo items, and not yet
supported.  At present, nilfs needs user's "copy back" operation to
roll back the state at T(N).

I think offline rollback is feasible, but I don't know whether it's
true of online rollback because the online rollback needs to discard
memory states of some sort or instead ensure consistency for the
processes which reside in the namespace of nilfs.  This may be done
in the same manner as file removal, but I don't know yet.

Cheers,
Ryusuke Konishi
--
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

Re: newbie question

[K. Richard Pixley]

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?

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

Re: newbie question

[Jiro SEKIBA]

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.

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.

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.

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

thanks,

regards,


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


-- 
Jiro SEKIBA <jir-hfpbi5WX9J54Eiagz67IpQ@public.gmane.org>
--
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

Re: newbie question

[K. Richard Pixley]

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

Re: newbie question

[K. Richard Pixley]

I don't know nilfs2 internals, but it occurs to me that a "forward" or 
"leap frog" mechanism might work too.

That is, if a file system is in a state at time T(0), and is in another 
state at time T(1), then what I'm looking for is the ability to return 
to a read-write file system with state T(0).

One way to do that might be to "roll back" from state T(1), thereby 
discarding state T(1).  But another way to accomplish this might be to 
surgically construct a state T(2) which occurs after T(1) and was 
identical to T(0), leaving T(1) available as a read-only snapshot.

We do this in source control.  Rather than backing out a particular 
change to your source tree, many source control systems require you to 
commit a reverse diff.  This creates a new revision, but a new revision 
which is identical to an earlier revision which has the apparent affect 
of removing a change.

I don't know if this would be any easier, but it's a thought.

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